Глава 2. Клиент-серверный вариант работы

«1С:Предприятие» позволяет работать с информационными базами в варианте клиент-сервер. В случае «1С:Предприятия» под вариантом клиент-сервер понимается архитектура, подразумевающая наличие следующих программных уровней:

● один из видов клиентского приложения «1С:Предприятия» (обычный клиент, тонкий клиент или веб-клиент);

● веб-сервер (только для веб-клиента и для тонкого клиента, подключенного через веб-сервер);

● кластер серверов «1С:Предприятия»;

● сервер баз данных.

На рис. 1 показана схема взаимодействия элементов системы.

Рис. 1. Схема взаимодействия элементов системы

Клиентские приложения, тонкие клиенты и веб-клиенты ‑ это и есть «1С:Предприятие» (в различных режимах запуска), с которым работает конечный пользователь. Для работы веб-клиента требуется только веб-браузер.

Кластер серверов «1С:Предприятия» является логическим понятием и представляет собой совокупность рабочих серверов, функционирующих на одном или нескольких компьютерах, и списка информационных баз, которые размещены в этом кластере.

Кластер серверов «1С:Предприятия» образует промежуточный программный слой между клиентским приложением и сервером баз данных. Клиентские приложения не имеют непосредственного доступа к серверу баз данных. Для доступа к информационной базе клиентское приложение взаимодействует с кластером серверов «1С:Предприятия».

Архитектура системы ориентирована на максимальный перенос выполнения всей функциональности на кластер серверов и максимальное «облегчение» клиента. В кластере серверов выполняется вся работа прикладных объектов, выполняется подготовка к отображению форм (чтение объектов из информационной базы и заполнение данных формы, расположение элементов, запись данных формы после изменения) и командного интерфейса, формируются отчеты. На клиенте выполняется только отображение информации, подготовленной в кластере серверов, выполняется взаимодействие с пользователем и вызовы серверных методов для выполнения необходимых действий.

Кроме того, на серверах, входящих в кластер серверов «1С:Предприятия», хранятся файлы, содержащие журналы регистрации информационных баз, зарегистрированных на данном сервере «1С:Предприятия», и другие служебные файлы. Все эти данные не являются жизненно необходимыми для работы с информационными базами, и их потеря не приведет к неработоспособности информационных баз. Также на серверах, входящих в кластер, выполняются фоновые задания.

Установка кластера серверов «1С:Предприятия» выполняется программой установки «1С:Предприятия». Настройка кластера серверов выполняется с помощью утилиты администрирования кластера серверов, входящей в комплект поставки.

Ключ аппаратной защиты кластера серверов «1С:Предприятия» не является сетевым, поэтому он должен быть подключен к каждому компьютеру, на котором функционируют рабочие процессы кластера.

Веб-сервер необходим для работы веб-клиента и одного из вариантов работы тонкого клиента. Фактически в случае работы через веб-сервер с кластером серверов взаимодействует именно веб-сервер. А уже веб-сервер взаимодействует с тонким и веб-клиентами.

Сервер баз данных. Хранение жизненно важных данных информационных баз «1С:Предприятия» в варианте клиент-сервер обеспечивается сервером баз данных. В качестве сервера баз данных в «1С:Предприятии» могут использоваться различные СУБД (см. здесь). При этом каждая информационная база целиком сохраняется в отдельной базе данных используемой СУБД.

Основной единицей кластера серверов выступает рабочий сервер. Рабочий сервер ‑ это компьютер, на котором выполняется агент сервера (ragent). Агент сервера «представляет» рабочий сервер в кластере серверов. Как правило, на одном компьютере располагается один рабочий сервер, однако в некоторых случаях (например, для целей отладки) возможна работа на одном физическом компьютере нескольких рабочих серверов. Рабочие серверы, расположенные на одном компьютере, должны иметь разные номера сетевых портов, идентифицирующих рабочий сервер, и работать с разными каталогами данных кластера.

Кластер серверов представляет собой один или несколько рабочих серверов. При этом информация о том, сколько рабочих серверов выполняется на одном физическом компьютере, не важна для описания и работы кластера. Для того чтобы «знать», для каких кластеров серверов данный рабочий сервер является центральным, агент сервера ведет реестр сервера. Реестр сервера представляет собой файл 1cv8wsrv.lst. В этом файле хранится следующая информация:

● список кластеров серверов, в состав которых входит данный рабочий сервер.

● список администраторов данного рабочего сервера.

Данный файл хранится в каталоге данных сервера (см. здесь). Фактически, агент сервера не входит в состав рабочего сервера, а лишь обеспечивает его работу (в том числе и «представительство» в кластере серверов).

Рис. 2. Общая схема сервера «1С:Предприятия»

В состав любого кластера должен входить минимум один рабочий сервер, у которого установлено свойство Центральный сервер. Максимальное количество центральных серверов не ограничено. Это означает, что для всех рабочих серверов, входящих в состав кластера серверов, можно установить флажок Центральный сервер. Рабочий сервер может быть центральным сервером в одном кластере и обычным (не центральным) ‑ в другом кластере серверов. Также, рабочий сервер с установленным признаком Центральный сервер, может выступать в качестве точки подключения к кластеру серверов, в состав которого он (рабочий сервер) входит.

Рабочая часть рабочего сервера включает в себя менеджер кластера (rmngr) и рабочий процесс (rphost). Менеджер кластера обеспечивает функционирование рабочего сервера и взаимодействие с другими рабочими серверами, входящими в состав кластера. Рабочий процесс непосредственно обслуживает клиентские приложения, взаимодействует с сервером баз данных, исполняет код, который в прикладном решении отмечен как выполняемый на сервере. Количество рабочих процессов определяется настройками рабочего сервера, кластера серверов и физическими характеристиками компьютера, на котором работает рабочий сервер.

В состав рабочего сервера может входить минимум один менеджер кластера. Если менеджер кластера работает на центральном сервере, то он называется главным менеджером кластера. Максимальное количество менеджеров кластера равно количеству сервисов кластера (см. здесь). Однако если один рабочий сервер входит в состав нескольких кластеров, то для каждого кластера будет создан минимум один менеджер кластера.

Главный менеджер кластера «ведет» реестр кластера. Реестр кластера представляет собой файл 1cv8clst.lst. В этом файле хранится следующая информация:

● список информационных баз, зарегистрированных в данном кластере;

● список рабочих серверов, входящих в кластер;

● список рабочих процессов, входящих в кластер;

● список менеджеров кластера;

● список сервисов кластера;

● список администраторов кластера.

Реестр кластера хранится в каталоге данных кластера. Этот каталог представляет собой каталог с именем вида reg_PORT, который расположен в каталоге данных сервера. PORT (в имени каталога данных кластера) ‑ это порт менеджера кластера (см. здесь). Если на рабочем сервере функционируют процессы нескольких кластеров, то в каталоге данных сервера будет находиться несколько каталогов данных кластера ‑ по одному на каждый кластер.

Если в состав кластера входит несколько центральных серверов, то реестр кластера ведется каждым из главных менеджеров кластера. Для того чтобы данные каждой копии реестра кластера были актуальными, внутри кластера серверов выполняется постоянная синхронизация реестра кластера между главными менеджерами кластера центральных серверов.

В самом простом случае, рабочий сервер и кластер серверов могут располагаться на одном компьютере, как показано на рис. 4.

Рис. 3. Простой вариант кластера

Взаимодействие различных процессов кластера серверов «1С:Предприятия» между собой и с клиентским приложением осуществляется по протоколу TCP/IP. Таким образом, каждый из процессов кластера адресуется именем рабочего сервера, на котором он запущен, и номером сетевого порта.

По умолчанию при установке кластера серверов используются следующие номера сетевых портов:

● Агент сервера ‑ порт 1540;

● Менеджер кластера ‑ порт 1541.

● Диапазон портов для динамического выбора ‑ порты 1560:1591. Из этого диапазона, по мере необходимости, выделяются сетевые порты для рабочих процессов и дополнительных менеджеров кластера. Выделение выполняется по следующему правилу:

● каждый рабочий процесс занимает один сетевой порт,

● каждый дополнительный менеджер кластера занимает один сетевой порт.

Необходимость создания дополнительных менеджеров кластера регулируется настройкой Менеджер под каждый сервис в свойствах рабочего сервера (см. здесь).

При необходимости можно изменить номера и диапазон используемых портов.

Рис. 4. Простой кластер

На приведенном рисунке имя центрального сервера ‑ 1C_Serv. Таким образом, сам центральный сервер адресуется как 1С_Serv:1540. Кластер, расположенный на этом сервере, адресуется как 1С_Serv:1541, а рабочий процесс ‑ 1С_Serv:1561.

Когда клиентское приложение пытается подключиться к информационной базе в варианте клиент-сервер, оно обращается по адресу кластера серверов: 1С_Serv:1541.

Рис. 5. Обращение к простому кластеру

Менеджер кластера выбирает рабочий процесс, который будет обслуживать клиентское приложение, и сообщает клиентскому приложению его адрес. В данном случае, поскольку рабочий процесс один, это будет 1С_Serv:1561.

Рис. 6. Установленное соединение

Клиентское приложение связывается с выделенным ему рабочим процессом, который выполняет аутентификацию пользователя информационной базы и осуществляет все дальнейшее взаимодействие клиентского приложения с информационной базой.

Вся функциональность менеджера кластера серверов разделена на несколько независимых сервисов. Каждый сервис обладает некоторыми характеристиками. Далее приведен список сервисов, с кратким описанием и указанием состава характеристик:

В таблице использованы следующие обозначения:

● Диск ‑ ресурсоемкий сервис, создает повышенную нагрузку на дисковую подсистему.

● Память ‑ ресурсоемкий сервис, создает повышенную нагрузку на процессор и оперативную память.

● Репликация ‑ поддерживается репликация между основным и резервными экземплярами сервиса. Репликация возникает в том случае, если уровень отказоустойчивости кластера отличен от 0 (см. здесь). Для сервисов конфигурации кластера и состояния кластера, репликация возникает в том случае, если в кластере зарегистрировано несколько рабочих серверов с установленным признаком Центральный сервер.

● Деление по ИБ ‑ для каждой информационной базы существует свой экземпляр сервиса.

● Возможность переноса между рабочими серверами:

● Перенос+ ‑ сервис может мигрировать между рабочими серверами без потери данных.

● Перенос– ‑ сервис может мигрировать между рабочими серверами с потерей данных.

● Не переносится ‑ сервис не может мигрировать между рабочими серверами и размещается только на компьютере центрального сервера кластера. Для таких сервисов не могут быть созданы требования назначения функциональности (см. здесь).

● Один сервер ‑ сервис не может мигрировать между рабочими серверами. Сервис может размещаться на любом одном рабочем сервере, а не только на центральном сервере.

● Каталог ‑ для сервиса предоставляется возможность изменить каталог хранения данных.

Сервисы кластера по типам сервисов, информационным базам и сеансам равномерно распределяются по рабочим серверам кластера.

Если в кластере серверов зарегистрирована хотя-бы одна модель распознавания речи, то в кластере запускается специальный менеджер кластера, который обслуживает сервис распознавания речи. Запуск этого менеджера кластера не зависит от флажка рабочего сервера Менеджер под каждый кластер. Сам процесс такого менеджера кластера будет именоваться rmstt.

Некоторые сервисы кластера серверов позволяют изменить местоположение каталога, в котором хранятся данные сервиса. В списке сервисов (см. здесь) эти сервисы отмечены обозначением Каталог. В этом случае данные сервиса кластера будут расположены в указанном каталоге, но структура хранения данных останется неизменной относительно мест хранения по умолчанию. Следующая таблица содержит список сервисов, поддерживающих перенос каталога хранения данных и каталог хранения данных по умолчанию:

В данном таблице приняты следующие допущения и обозначения:

● <sdf> ‑ каталог данных сервера (см. здесь). При расположении по умолчанию, данный каталог в точности совпадает с каталогом, который указан при запуске агента сервере (параметр команды /d командной строки запуска агента сервера). Значение port в фрагменте пути reg_<port> соответствует номеру сетевого порта главного менеджера кластера (параметр команды /regport командной строки запуска агента сервера).

● <uuid-db> ‑ уникальный идентификатор информационной базы в данном кластере серверов.

● <uuid-rmngr> ‑ уникальный идентификатор менеджера кластера.

После переназначения, каталог данных сервиса меняется следующим образом: часть пути, которая ссылается на каталог данных сервера (обозначенный, в таблице выше, как <sdf>), заменяется на путь, указанный в настройке сервиса. Остальные фрагменты пути сохраняются в том виде, какими были до переназначения. Например, текущий каталог данных кластера: d:\cluster_data, для сервиса хранилища двоичных данных указан новый путь e:\storage\bds. В этом случае полный путь к данным сервиса хранилища двоичных данных будет выглядеть следующим образом:

● До переназначения: d:\cluster_data\reg_1541\BinDataStrg\<uuid-db>.

● После переназначения: e:\storage\bds\reg_1541\BinDataStrg\<uuid-db>.

Если сервис делится по информационным базам, но никакие информационные базы указаны не были, то используется общий каталог для всех баз кластера серверов, аналогично тому, как это делается в настройках кластера по умолчанию. Если сервис может делить по информационным базам, то можно изменить как общий каталог размещения данных, так и каталог конкретной информационной базы. В этом случае данные сервиса будут располагаться следующим образом:

● Для тех информационных баз, которые явно указаны в настройках, будут использоваться «персональные» каталоги. При этом структура каталогов размещения данных сохранится.

● Все остальные информационные базы будут размещаться в общем каталоге (или каталоге по умолчанию).

Если каталог данных изменяется для сервисов журналов регистрации или хранилища двоичных данных, то перенос данных этих сервисов требуется в обязательном порядке. Если этот перенос не будет выполнен, то кластер серверов может перейти в неработоспособное состояние. Следует понимать, что перенос данных выполняется администратором! Кластер серверов автоматически перенос данных не выполняет.

Для остальных сервисов кластера перенос каталога работающего сервиса без переноса данных может привести к замедлению работы кластера и временной неработоспособности части функциональности. Не рекомендуется назначать в качестве рабочего каталога сервиса кластера сетевой ресурс, т. к. это приведет к снижению производительности кластера. Также не рекомендуется назначать один и тот же каталог для сервисов из разных кластеров серверов. Такую «уникальность» администратор должен отслеживать вручную.

Для изменения каталога данных кластера используется объект настройки сервисов. Управление этими объектами поддерживается как в интерактивном режиме (в консоли управления кластером серверов или стандартной обработке управления серверами) так и с помощью объектной модели встроенного языка.

Общая схема переноса каталога данных сервиса кластера выглядит следующим образом:

● Администратор кластера серверов создает настройки сервисов для выбранных сервисов кластера.

● Запрещается подключение пользователей и начало работы регламентных заданий.

● Завершаются все фоновые задания.

● Выполняется завершение работы всех пользователей.

● Применяются созданные настройки.

● Завершается работа кластера серверов.

● Выполняется перенос данных сервисов кластера в новые каталоги.

● Запускается кластер серверов, сервисы которого будут использовать уже новые каталоги данных.

● Восстанавливается возможность работы пользователей и регламентных заданий.

Перезапуск кластера (и завершение работы пользователей) необходимо выполнять потому, что фактическое применение измененных каталогов сервисов кластера выполняется при запуске кластера серверов. Поэтому даже если происходит изменение каталога хранения журнала регистрации одной информационной базы, необходимо перезапускать весь кластер серверов. В связи с этим рекомендуется тщательно продумывать размещение новых каталогов данных сервисов кластера перед тем, как администратор начнет фактическое создание новых настроек сервисов и перенос данных.

Смотри также:

● Механизм распознавания речи (см. здесь).

● Администрирование рабочего сервера (см. здесь).

● Работа с настройками сервисов (см. здесь).

Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Активным пользователем может являться:

● экземпляр клиентского приложения «1С:Предприятия»;

● экземпляр веб-приложения, в котором исполняется веб-клиент;

● экземпляр внешнего соединения (полученный из объекта V83.COMConnector);

● один экземпляр фонового задания;

● одно обращение к Web-сервису.

Сеансы могут быть активными и спящими. Одно из назначений спящего сеанса ‑ сохранение работоспособности клиентского приложения после перехода клиентского компьютера в различные режимы энергосбережения. Сеанс переходит в спящее состояние в двух случаях:

● При нештатном разрыве соединения, назначенного сеансу (для толстого клиента, внешнего соединения, тонкого клиента при прямом соединении с сервером). При физическом отключении сети сервер обнаруживает разрыв соединения с клиентским приложением в течение 2-3 минуты.

● По истечении интервала времени, в течение которого клиентское приложение, использующее сеанс, не проявляется активности (для веб-клиента и тонкого клиента при подключении через веб-сервер). Если компьютер клиента не находится в режиме энергосбережения, и клиентское приложение бездействует (не выполняет никаких действий пользователя), то оно периодически вызывает сервер «1С:Предприятия» с интервалом 5-10 минут для поддержания активности сеанса. Поэтому не рекомендуется устанавливать время засыпания сеанса меньше 10 минут.

Любая активность клиентского приложения, использующего сеанс, приводит к пробуждению сеанса. Спящий сеанс завершается в следующих случаях:

● По истечении интервала времени, который определяет время жизни спящего сеанса.

● Если блокировки, установленные спящим сеансом, конфликтуют с блокировками, которые пытаются установить активные сеансы.

Сеанс, который переходит в спящее состояние, освобождает занятую им клиентскую лицензию. При активизации спящего сеанса он пытается получить клиентскую лицензию (если до перехода в спящий режим сеанс занимал клиентскую лицензию). Невозможность получения лицензии приводит к невосстановимому исключению и завершению сеанса.

Время перевода пассивного сеанса в спящее состояние и время, по истечении которого спящий сеанс будет завершен, задается в диалоге настройки параметров информационной базы, которые редактируются с помощью конфигуратора. Подробное описание диалога редактирования параметров информационной базы приводится в книге.

Все данные, хранимые кластером, которые относятся к одному активному пользователю и актуальны только на время работы этого пользователя, являются данными сеанса. К данным сеанса относятся:

● информационная база,

● номер сеанса,

● аутентифицированный пользователь информационной базы,

● язык интерфейса,

● значения параметров сеанса,

● временные хранилища,

● статистика работы сеанса,

● информация форм управляемого приложения,

● некоторые внутренние данные платформы.

Данные сеансов сохраняет менеджер кластера. Для этого предусмотрен сервис сеансовых данных (см. здесь). При перезапуске кластера серверов данные сеансов сохраняются. Если активный пользователь не выполнил ни одного обращения к кластеру за определенный интервал времени и сеанс не назначен соединению, то сеанс переводится в спящее состояние. Интервал времени неактивности настраивается в параметрах информационной базы (в конфигураторе). Значение по умолчанию равно 1200 секунд. Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут. Для ускорения доступа данные сеансов кешируются в рабочих процессах и в толстых клиентах. В списке активных пользователей показывается список активных сеансов.

Изменения данных сеанса, выполненные за время одного вызова сервера, хранятся в рабочем процессе и передаются менеджеру кластера только при возврате управления клиенту, как штатного, так и в результате программного исключения.

Изменения данных сеанса не сохраняются в менеджере кластера, если:

● в процессе вызова сервера аварийно завершился рабочий процесс;

● при возврате управления клиенту произошла ошибка передачи данных.

Соединение является средством доступа сеансов к кластеру серверов «1С:Предприятия», содержит ограниченное множество данных соединения, не отождествляется с активным пользователем. Также соединения используются для взаимодействия процессов кластера.

Для обращения клиента к кластеру сеанс назначается соединению. Все время, пока клиент не выполняет обращений к кластеру, сеанс может быть не назначен никакому соединению.

Разные варианты использования «1С:Предприятия» по-разному работают с сеансами и соединениями.

● Конфигуратор и толстый клиент:

● при старте: устанавливает соединение, начинает сеанс и назначает его соединению;

● при завершении: отменяет назначение сеанса соединению, заканчивает сеанс и разрывает соединение.

● Одно обращение к Web-сервису и одно выполнение фонового или регламентного задания:

● в начале обращения: выбирает соединение из пула, создает сеанс и назначает его соединению;

● в конце обращения: отменяет назначение сеанса соединению, заканчивает сеанс и возвращает соединение в пул.

● Тонкий клиент и веб-клиент начинают сеанс при старте и заканчивают сеанс при завершении:

● в начале обращения к кластеру выбирается соединение из пула, и ему назначается сеанс данного клиента.

● в конце обращения к кластеру назначение сеанса соединению отменяется, и соединение возвращается в пул.

Информация о сеансах отражается:

● в журнале регистрации,

● консоли кластера,

● средствах программного администрирования,

● технологическом журнале,

● глобальном контексте.

Администратор кластера может получить список существующих сеансов как для всего кластера, так и в разрезе информационных баз. Для этого утилита администрирования кластера и средства программного администрирования имеют соответствующие возможности.

Администратор кластера может закончить сеанс принудительно при помощи утилиты администрирования кластера и средств программного администрирования. При этом работа активного пользователя завершится аварийно. Если удаляется сеанс, назначенный соединению, то происходит разрыв этого соединения.

Администратор кластера с помощью утилиты администрирования и средств программного администрирования может установить блокировку установки сеансов, которая не позволяет начинать новые сеансы, но при этом не препятствует работе существующих сеансов.

Можно выделить два вида соединений:

● соединения с информационной базой,

● служебные соединения с рабочими процессами кластера.

Соединения с информационной базой имеют следующие отличительные особенности:

● соединение выполняется с конкретной информационной базой кластера;

● в таком соединении может выполняться код на встроенном языке;

● соединение может переустанавливаться с течением времени;

● соединение может быть разорвано принудительно командой консоли кластера или средствами встроенного языка;

● наличие соединений с информационной базой у рабочего процесса кластера препятствует остановке и запуску этого рабочего процесса.

Возможны следующие виды соединений с информационной базой:

● Толстый клиент,

● Тонкий клиент,

● Конфигуратор,

● Модуль расширения веб-сервера,

● COM-соединение,

● Фоновое задание,

● Системное фоновое задание.

Толстый клиент

Представляет собой соединение толстого клиента с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

Соединение Толстый клиент создается в результате интерактивного запуска толстого клиента в режиме 1С:Предприятие или в результате подключения к информационной базе с использованием технологии Automation Client/Server, например:

// Создать Automation сервер 1С:Предприятия
AutomationCервер = Новый COMОбъект("V83.Application");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
AutomationCервер.Connect("Srvr="TestSrv";Ref="TestBase");

Тонкий клиент

Представляет собой соединение тонкого клиента с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

Соединение Тонкий клиент создается в результате интерактивного запуска тонкого клиента или в результате подключения к информационной базе с использованием технологии Automation Client/Server, например:

// Создать Automation сервер 1С:Предприятия
AutomationCервер = Новый COMОбъект("V83С.Application");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
AutomationCервер.Connect("Srvr="TestSrv";Ref="TestBase");

Конфигуратор

Представляет собой соединение конфигуратора с информационной базой. Это соединение предназначено для создания и модификации конфигурации информационной базы и для выполнения административных и регламентных действий.

Модуль расширения веб-сервера

Представляет собой соединение веб-сервера с рабочим процессом сервера. Это соединение предназначено для работы веб-клиента, интернет-сервисов, тонкого клиента (по протоколу HTTP), а также мобильного клиента.

Соединение создается в момент обращения к интернет-сервису или при обращении веб-клиента, тонкого клиента (по протоколу HTTP) или мобильного клиента к серверу «1С:Предприятия». Соединение существует до перезапуска веб-сервера или до тех пор, пока соединение находится в пуле соединений модулей расширений веб-сервера (пока не закончится время жизни соединения в пуле, или пока данное соединение не будет вытеснено из пула другими соединениями).

Смотри также:

● Интернет-сервисы (см. здесь).

● Мобильный клиент (см. здесь).

COM-соединение

Представляет собой соединение процесса, использующего функциональность внешнего соединения «1С:Предприятия», с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

COM-соединение создается в результате подключения к информационной базе с использованием технологии COM, например:

// Создать Automation сервер 1С:Предприятия
COMСоединитель = Новый COMОбъект("V83.COMConnector");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
СоединениеСИнформационнойБазой = COMСоединитель.Connect("Srvr="TestSrv";Ref="TestBase");

Фоновое задание

Представляет собой соединение рабочего процесса кластера с информационной базой. Это соединение предназначено для выполнения кода процедуры фонового задания.

Соединение фонового задания создается в случае:

● Получения платформой списка регламентных заданий, зарегистрированных в информационной базе;

● Запуска платформой зарегистрированного в информационной базе регламентного задания;

● Запуска фонового задания на выполнение из встроенного языка;

● Фонового исполнения отчета,

● Фонового поиска по подстроке,

● Фонового запроса списка,

● Запуска фоновой реструктуризации.

В частности, запуск фонового задания может выполняться разработчиком, средствами встроенного языка, например:

// Выполнить фоновое задание, описанное в процедуре
// ОбновлениеИндексаПолнотекстовогоПоиска
// общего модуля РегламентныеПроцедуры
ФоновоеЗадание = ФоновыеЗадания.Выполнить("РегламентныеПроцедуры.ОбновлениеИндексаПолнотекстовогоПоиска");

Соединение фонового задания существует до тех пор, пока существует контекст исполняемой процедуры фонового задания. После того как процедура выполнена или отчет сформирован, соединение фонового задания закрывается.

Системное фоновое задание

Представляет собой соединение рабочего процесса кластера с информационной базой. Это соединение предназначено для различных операций, которые система выполняет с информационной базой во время работы кластера. В рамках этого соединения могут выполняться следующие действия (список не является исчерпывающим):

● Фоновое обновление конфигурации информационной базы. Соединение фонового задания существует до тех пор, пока выполняется фоновая реструктуризация. Подробнее о фоновом обновлении конфигурации базы данных написано в книге.

● Обработка оповещений копий базы данных.

● Обработка оповещений механизма копий базы данных.

● Обработка изменений административных параметров и профиля безопасности информационной базы.

● Различные сервисные операции с информационной базой:

● Предварительная загрузка контекста информационной базы в резервном рабочем процессе.

● Пересчет итогов.

● Параллельная загрузка и выгрузка информационной базы.

● Тестирование и исправление.

Смотри также:

● Фоновые задания (см. здесь).

● Фоновое исполнение отчетов (см. здесь).

Служебные соединения имеют следующие отличительные особенности:

● соединение выполняется с рабочим процессом и не ассоциируется с конкретной информационной базой;

● в служебных соединениях код на встроенном языке не выполняется;

● соединение не может быть разорвано принудительно, оно создается и завершается системой;

● наличие служебных соединений не препятствует остановке и запуску рабочих процессов кластера серверов.

Возможны следующие виды служебных соединений:

● Планировщик заданий,

● Отладчик,

● Консоль кластера,

● Сервер администрирования,

● COM-администратор.

Планировщик заданий

Представляет собой соединение планировщика заданий с рабочим процессом. Это соединение предназначено для управления работой фоновых заданий, в том числе для запуска регламентных заданий по расписанию. Данное соединение также используется для других случаев обращения менеджера кластера (rmngr) к рабочему процессу (rphost), например, при получении списка сеансов.

Соединение планировщика заданий создается при первом запуске фонового задания. Оно может порождать соединение фонового задания с информационной базой в том же рабочем процессе кластера серверов. После завершения соединения фонового задания соединение планировщика заданий не завершается, а существует до тех пор, пока рабочий процесс кластера не будет выключен или удален.

Подробнее о фоновых заданиях написано в книге.

Отладчик

Представляет собой соединение отладчика с рабочим процессом кластера, находящимся в режиме отладки. Это соединение предназначено для управления ходом отладки и поиском предметов отладки, имеющихся в настоящий момент.

Соединение отладчика создается при подключении предмета отладки или при поиске предметов отладки. Существует до тех пор, пока предмет отладки не будет отключен или не завершит свою работу.

Подробнее об отладчике написано в книге.

Консоль кластера

Представляет собой соединение консоли кластера серверов (mmc, см. здесь) с рабочим процессом. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение консоли кластера создается в момент обращения к данным рабочего процесса (например, при получении параметров информационной базы, при получении подробного списка соединений информационной базы и пр.).

Сервер администрирования

Представляет собой соединение сервера удаленного администрирования кластера серверов с рабочим процессом. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение удаленного администрирования создается в момент обращения к данным рабочего процесса (например, при получении параметров информационной базы, при получении подробного списка соединений информационной базы и пр.).

COM-администратор

Представляет собой соединение с рабочим процессом сервера с использованием технологии COM. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение COM-администратора создается при подключении к выбранному рабочему процессу с использованием технологии COM, например:

// Создать COMСоединитель 1С:Предприятия
COMСоединитель = Новый COMОбъект("V83.COMConnector");
// Установить соединение с рабочим процессом 1562
// в кластере 1541 центрального сервера TestSrv
СоединениеСРабочимПроцессом = COMСоединитель.ConnectWorkingProcess("tcp://TestSrv:1562");

Возможны следующие виды сеансов:

● COM-администратор,

● COM-соединение,

● WS-соединение,

● Веб-клиент,

● Запрос системы аналитики,

● Клиент системы аналитики,

● Консоль кластера,

● Конфигуратор,

● Мобильный клиент,

● Сервер администрирования,

● Толстый клиент,

● Тонкий клиент,

● Фоновое задание.

Описание сеансов, в общем, соответствует описанию соответствующих соединений. Описание отличающихся сеансов приведено далее.

Веб-клиент

Является представлением в кластере серверов экземпляра веб-клиента. Этот сеанс предназначен для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы. Обращение веб-клиента к серверу выполняется через соединение Модуль расширения веб-сервера.

Сеанс Веб-клиент создается в результате интерактивного запуска веб-клиента и существует до тех пор, пока не будет завершен сеанс интерактивной работы с информационной базой (закрыто последнее окно веб-браузера).

Запрос системы аналитики

Является представлением в кластере серверов системы аналитики. Сеанс используется для выполнения запросов системы аналитики к кластеру серверов системы «1С:Предприятие». Запрос системы аналитики к серверу выполняется через соединение Модуль расширения веб-сервера.

Сеанс Запрос системы аналитики стартует при необходимости получения системой аналитики каких-либо данных от кластера серверов «1С:Предприятие». Параметры завершения сеанса определяются параметрами пула сеансов.

Клиент системы аналитики

Является представлением в кластере серверов системы аналитики. Сеанс используется для взаимодействия системы аналитики и кластера серверов системы «1С:Предприятие» (кроме выполнения запросов). Обращение клиента системы аналитики к серверу выполняется через соединение Модуль расширения веб-сервера.

Сеанс Клиент системы аналитики стартует при старте системы аналитики из клиентского приложения «1С:Предприятие» и завершается либо в случае выхода пользователя из системы, либо в соответствии с параметрами автоматического завершения сеанса (аналогично веб-клиенту).

Мобильный клиент

Является представлением в кластере серверов экземпляра мобильного клиента. Этот сеанс предназначен для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы. Обращение веб-клиента к серверу выполняется через соединение Модуль расширения веб-сервера.

Сеанс Мобильный клиент создается в результате запуска мобильного клиента на мобильном устройстве и существует до тех пор, пока не будет завершен сеанс работы с информационной базой (закрыто мобильное приложение на мобильном устройстве).

Описание механизма см. здесь.

Отказоустойчивый кластер обеспечивает бесперебойную работу пользователей в следующих случаях:

● перезапуск рабочих процессов и менеджеров кластера (как плановый, так и аварийный);

● выход из строя сервера, входящего в состав кластера.

Механизмы, которые обеспечивают бесперебойную работу, описаны далее в этом разделе.

В процессе работы системы сеанс сохраняется при различных сбоях, и возможно восстановление работы после переустановки соединения. Однако существуют ситуации, при которых сеанс завершается системой и предлагается выполнить перезапуск клиентского приложения:

● в процессе вызова сервера, после фиксации первой за этот вызов транзакции, аварийно завершился рабочий процесс;

● при возврате управления клиенту произошла ошибка передачи данных.

Если в процессе вызова сервера произошла ошибка передачи данных, то это может означать, что:

● произошел обрыв канала связи,

● произошло аварийное завершение рабочего процесса сервера.

Если клиентское приложение вызвало сервер вне транзакции и ошибка передачи данных получена клиентом до фиксации первой за вызов сервера транзакции, то клиент автоматически выполняет процедуру установки соединения с сервером и повторяет тот же самый вызов. После этого его работа продолжается.

Если ошибка передачи данных получена клиентом после фиксации первой за вызов сервера транзакции, то сеанс этого клиента завершается и для продолжения работы требуется перезапуск клиентского приложения.

Если клиентское приложение вызвало сервер в транзакции (в обычном режиме работы, а не в режиме управляемого приложения), то ошибка передачи данных считается восстановимой ошибкой и приводит к аварийному завершению интерактивного действия, но не к аварийному завершению клиентского приложения.

Важно, что целостность данных приложения в этом случае не гарантируется платформой, если интерактивное действие состоит более чем из одной транзакции или меняет состояние данных приложения, кроме данных, имеющих логику кеширования.

При аварийном завершении рабочего процесса, кластер серверов запускает новый рабочий процесс. Затем выполняется попытка перенести все клиентские сеансы, которые обслуживал завершившийся рабочий процесс, на новый рабочий процесс. Это приводит к тому, что пользователи могут наблюдать существенные паузы в работе: клиентское приложение перестает реагировать на пользовательские команды, создается ощущение, что клиентское приложение «зависло».

Чтобы уменьшить остроту проявления проблемы переключения существующих сеансов, кластер серверов предлагает возможность создания специальных, резервных, рабочих процессов. Резервирование рабочих процессов включается в разрезе информационных баз. Информационные базы, для которых включено резервирование рабочих процессов, будут называться резервируемыми. Администратор может указать, для каких информационных баз будут создаваться резервные рабочие процессы.

Логика работы при этом следующая:

● На рабочих серверах, которые обслуживают резервируемые информационные базы, запускаются резервные рабочие процессы.

● Эти рабочие процессы загружают метаданные резервируемых информационных баз.

● В случае необходимости, клиентские сеансы переключаются на резервные рабочие процессы, в которые уже загружена вся необходимая информация. Такое переключение выполняется достаточно быстро.

● После того, как резервный рабочий процесс становится обычным, с резервного рабочего процесса снимается признак резервного и кластер серверов восстанавливает количество необходимых резервных рабочих процессов с помощью запуска новых, резервных, рабочих процессов.

Количество резервных рабочих процессов определяется свойством рабочего сервера Количество ИБ на процесс. Необходимость резервировать рабочие процессы управляется флажком Резервирование рабочих процессов в свойствах информационной базы (в консоли кластера). Если рабочий процесс выступает в роли резервного, в его свойствах устанавливается флажок Резервный. Данный флажок сбрасывается при переходе рабочего процесса в роль активного рабочего процесса.

Смотри также:

● Просмотр свойств информационной базы (см. здесь).

● Просмотр свойств рабочего процесса (см. здесь).

● Просмотр свойств рабочего сервера (см. здесь).

Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.

Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.

Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.

Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогут подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.

Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.

Выход из строя одного рабочего сервера

Аварийно завершается работа обычного рабочего сервера. Это соответствует уровню отказоустойчивости, кластер продолжает обслуживать пользователей. При этом подключение новых пользователей также возможно, т. к. сохраняет работоспособность центральный сервер.

Рис. 7. Аварийное завершение одного рабочего сервера

Выход из строя центрального сервера

Аварийно завершается работа центрального сервера. Это соответствует уровню отказоустойчивости, но кластер прекращает работу, т. к. завершил работу центральный сервер кластера.

Рис. 8. Аварийное завершение центрального сервера

Выход из строя двух рабочих серверов

Аварийно завершают работу два рабочих сервера, при этом центральный сервер сохраняет работоспособность. При этом превышен уровень отказоустойчивости, как следствие, будут завершены сеансы пользователей, которые обслуживались завершившимися рабочими серверами. Пользователи, которых обслуживает центральный сервер ‑ сохранят работоспособность. При этом будет возможно подключение новых пользователей.

Рис. 9. Аварийное завершение двух рабочих серверов

Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости: Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.

Системы балансировки нагрузки и обеспечения отказоустойчивости кластера для своей работы используют TCP-соединения (сетевые соединения) между компонентами кластера. TCP-соединения также используются при прямом (без использования веб-сервера) подключении клиентского приложения (как тонкого, так и толстого) к серверу «1С:Предприятия». Если доступность компонентов кластера определяется неверно, то и механизмы, опирающиеся на доступность компонентов, будут работать неадекватно или некорректно. Для корректного определения доступности компонентов кластера существует система отслеживания разрыва соединений между компонентами кластера.

Данная система отслеживает сетевые соединения между процессами кластера серверов (как на одном компьютере, так и на разных компьютерах), между кластером серверов и расширением веб-сервера, а также между клиентским приложением и кластером серверов, для достижения следующих целей:

● Оперативного обнаружения разрыва соединения между компонентами.

● Снижения накладных расходов на отслеживание целостности соединений между компонентами кластера.

Для целей проверки используется понятие направление проверки. Направление проверки ‑ это группа соединений между компонентами кластера серверов, объединенных по следующим правилам:

● Исходящие соединения ‑ по целевому адресу (имя компьютера и порт, однозначно идентифицирующие определенный компонент кластера серверов).

● Входящие соединения от расширения веб-сервера ‑ по уникальному идентификатору, однозначно определяющему публикацию информационной базы на веб сервере;

● Остальные входящие соединения ‑ по уникальному идентификатору, однозначно определяющему процесс источника.

Для каждого направления происходит периодическая отправка небольшого пакета данных и ожиданием ответа на него. Проверка осуществляется как на стороне источника соединений, так и на целевой стороне. Параметры проверки передаются со стороны источника соединений.

Пакеты отправляются и ожидаются по протоколам UDP и TCP. Изначально пакеты отправляются по протоколу UDP и, если в ответ не пришло ни одного ответа за все время жизни направления, то, при наступлении таймаута, устанавливается TCP-соединение и попытка проверки выполняется через это новое соединение. При этом направление продолжает считаться доступным. Режим проверки по протоколу TCP менее точен и может приводить к ложным срабатываниям при установке небольших таймаутов. При настройке кластера серверов и публикации информационных баз на веб-сервере, рекомендуется обеспечить взаимную доступность между всеми компьютерами кластера, а также между компьютерами кластера и компьютерами веб-серверов, как по протоколу TCP, так и по протоколу UDP (с теми же номерами портов). Работой системы отслеживания можно управлять с помощью двух параметров:

1. Период проверки ‑ интервал времени, который проходит между отправкой тестового пакета.

2. Таймаут проверки ‑ период времени, в течение которого отправитель сообщения должен получить хотя-бы один ответный пакет по выбранному направлению. Интервал времени измеряется от предыдущего получения ответного пакета (или начал работы системы).

Если за период таймаута проверки не пришло ни одного пакета от противоположной стороны, направление проверки считается недоступным, кроме случая, когда происходит переключение с протокола UDP на протокол TCP. После того, как направление проверки признано недоступным, все соединения этого направления отмечаются как непригодные для использования и будут разорваны при первом следующем обращении к ним. Одновременно с отметкой, все доступные компоненты кластера серверов оповещаются о разрыве соединений определенного направления для того, чтобы кластер мог оперативно отреагировать на грядущий разрыв соединений (в том числе для удаления блокировок, соответствующих недоступному процессу).

Администратор кластера серверов имеет возможность отслеживать качество соединения между компонентами кластера. Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN. Более подробное описание выводимой информации приведено в книге.

Если какой-либо из параметров настройки системы отслеживания разрыва соединений установлен в 0, то система отслеживания разрывов соединений начинает работать по другому алгоритму. В этом случае проверка выполняется только той стороной, которая инициировала установку сетевого соединения, при этом отсылка тестовых пакетов выполняется каждые 5 секунд. Процесс-приемник тестовых пакетов определяет разрыв соединения в том случае, если он не получил ни одного пакета в течение 200 секунд. Процесс-источник узнает о разрыве соединения только после наступления таймаута TCP-соединения, время которого определяется настройками операционной системы. При такой настройке системы отслеживания разрыва соединений период отправки сообщений и таймаут не настраивается, в технологический журнал информация о статистике соединений не выводится. Такой вариант настроек (период проверки или таймаут проверки установлены в значение 0) системы отслеживания разрыва соединений не рекомендуется к применению.

При отслеживании разрыва соединения между клиентским приложением и кластером серверов периоды и таймауты проверки фиксированы и не могут быть изменены:

● для толстого клиента:

● период проверки ‑ 12 секунд;

● таймаут проверки ‑ 60 секунд.

● для тонкого клиента:

● период проверки ‑ 3 секунды;

● таймаут проверки ‑ 15 секунд.

Период и таймаут проверки соединений между расширением веб-сервера и кластером серверов по умолчанию равны 3 и 15 секунд и могут быть изменены параметрами публикации информационной базы на веб-сервере (подробнее см. здесь).

Период и таймаут проверки соединений между процессами кластера серверов по умолчанию равны 1 и 5 секунд и могут быть изменены параметрами запуска агентов сервера (подробнее см. здесь).

Масштабируемость кластера серверов обеспечивается несколькими способами:

● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.

● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.

Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.

В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер. При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер.

Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.

Во время установки соединения с информационной базой, кластер серверов выбирает рабочие сервера с максимальной доступной производительностью (на момент выбора рабочего сервера). Существующие соединения могут быть перемещены на другой рабочий сервер. Более подробное описание этого механизма см. здесь.

Описание других свойств, управляющих работой рабочего сервера, см. здесь.

Каждый рабочий процесс имеет свойство Доступная производительность. Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонные операции по сравнению с другими рабочими процессами. Эталонные операции состоят из:

● Операции с памятью: выделение массива, заполнение массива, освобождение массива.

● Операции с файлами: создание, запись, удаление.

● Определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения.

При работе под управлением ОС Windows пользователь, от имени которого работает сервер, должен входить в группу Пользователи журналов производительности (Performance Log Users). В противном случае определение степени загрузки процессора не выполняется.

Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонных операций текущим рабочим процессом. Измерение скорости выполнения эталонных операций выполняется каждые 5 секунд.

Для рабочего сервера доступной производительностью будет считаться доступная производительность самого быстрого рабочего процесса этого рабочего сервера (рабочего процесса с максимальной доступной производительностью).

Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.

При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.

При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.

При установке нового соединения с сервером «1С:Предприятия», системе можно указать, каким образом выбирать рабочий процесс (свойство кластера серверов Режим распределения нагрузки):

● Приоритет по производительности,

● Приоритет по доступной памяти.

Выбирается список подходящих рабочих серверов, в который входят сервер с максимальной доступной производительностью и сервера, чья доступная производительность не больше, чем на 25% меньше максимальной (первый выбранный рабочий сервер).

На каждом подходящем рабочем сервере выбирается лучший рабочий процесс. При выборе рабочего процесса считается, что:

● предпочтительнее рабочий процесс, который уже обслуживает информационную база для которой устанавливается соединение, чем тот, который не обслуживает эту информационной базу;

● предпочтительнее активный рабочий процесс, чем резервный;

● предпочтительнее рабочий процесс, в котором больше соединений с информационной базой, для которой устанавливается соединение;

● предпочтительнее рабочий процесс, в котором больше соединений с любой информационной базой.

Соединение будет назначено на лучший рабочий процесс случайного рабочего сервера, из списка рабочих серверов, который соответствует вышеприведенным критериям.

Существующее соединение с сервером «1С:Предприятия» может быть переустановлено с другим рабочим процессом в одном из следующих случаев:

● Текущий рабочий процесс выключен.

● Доступная производительность текущего рабочего процесса составляет менее 75% доступной производительности самого производительного рабочего сервера.

Переустановка соединения возможна, если выполняются все указанные условия:

● клиентский поток не исполняется на сервере;

● нет открытой транзакции;

● не создано ни одной временной таблицы.

Выбирается список подходящих рабочих серверов, в который входят сервер с максимальной доступной производительностью и сервера, чья доступная производительность не больше, чем на 75% меньше максимальной (первый выбранный рабочий сервер).

На рабочих серверах из получившегося списка рассматриваются только те рабочие процессы, которые уже обслуживают требуемую информационную базу, для которой устанавливается соединение. Если таких рабочих процессов нет ‑ рассматриваются все рабочие процессы на рабочих серверах из получившегося списка.

Среди рассматриваемых рабочих процессов выбирается случайный рабочий процесс на рабочем сервере с наибольшим количеством свободной оперативной памяти, на который и назначается соединение.

Существующее соединение с сервером «1С:Предприятия» может быть переустановлено с другим рабочим процессом в одном из следующих случаев:

● Текущий рабочий процесс выключен;

● Доступная производительность текущего рабочего процесса составляет менее 25% доступной производительности самого производительного рабочего сервера.

Переустановка соединения возможна, если выполняются все условия, перечисленные ниже:

● клиентский поток не исполняется на сервере,

● нет открытой транзакции,

● не создано ни одной временной таблицы.

При выполнении обращения к серверу от имени нового сеанса система:

● Выбирает любое соединение из пула соединений, который существует у расширения веб-сервера.

● Если в пуле нет свободных соединений, то производится создание нового соединения в соответствии с параметром кластера Режим распределения нагрузки.

При выполнении обращения от имени существующего сеанса:

● В пуле соединений выполняется поиск соединения с тем же рабочим процессом, через который выполнялось взаимодействие в прошлый вызов. В случае успеха ‑ используется найденное соединение.

● Происходит попытка выбора рабочего процесса, в соответствии с параметром кластера Режим распределения загрузки, при этом приоритет в поиске отдается рабочему процессу, через который выполнялось предыдущее обращение к серверу. Новый рабочий процесс будет выбран в том случае, если он существенно лучше (по производительности или свободной памяти), чем «старый» рабочий процесс. Если к полученному рабочему процессу есть свободные соединения ‑ будет использовано одно из них.

● Иначе происходит создание нового соединения в соответствии с параметром кластера Режим распределения загрузки.

Кластер серверов позволяет управлять запуском регламентных заданий в том случае, когда в информационной базе отсутствуют активные сеансы пользователей. Это параметры Минимальный период запуска регламентных заданий, Максимальный сдвиг запуска регламентных заданий.

Введем некоторые определения. Будем считать информационную базу пассивной, если в ней отсутствуют не спящие сеансы пользователей и обслуживающие их соединения. Иначе информационную базу считаем активной.

В рамках описания данного механизма будет использовано следующее разбиение на сеансы, которые являются «сеансами пользователей» и которые таковыми не являются:

● Являются сеансами пользователей:

● Конфигуратор.

● Толстый клиент.

● Тонкий клиент с прямым подключением к кластеру северов.

● Сеансы, использующие для своей работы соединение Модуль расширения веб-сервера (Веб-клиент, Запрос системы аналитики, Клиент системы аналитики, Мобильный клиент, Тонкий клиент с подключением через веб-сервер).

● COM-соединение (с временем работы более 20 секунд).

● Не являются сеансами пользователей:

● Сеансы, использующие для своей работы соединение Модуль расширения веб-сервера WS-соединение, но не являющиеся клиентскими приложениями: Интернет-сервисы (HTTP- и Web-сервисы)

● COM-соединение (с временем работы менее 20 секунд)

● Фоновое задание (включая боты и сервисы интеграции)

Регламентные задания запускаются в полном соответствии с расписанием в следующих случаях:

● В активной информационной базе.

● В пассивной информационной базе, если значения параметров Минимальный период запуска регламентных заданий и Максимальный сдвиг запуска регламентных заданий установлены в значение 0.

В пассивной информационной базе, от момента последнего запуска задания в активной базе по расписанию, отсчитываются интервалы времени, равные Минимальный период запуска регламентных заданий. Все задания, которые по расписанию должны были быть запущены в течение данного интервала, запускаются через случайное время от 0 до Максимальный сдвиг запуска регламентных заданий после окончания интервала. Запуск заданий группируется, чтобы выполнить их за одну загрузку контекста информационной базы. Задание, определяемое одним объектом РегламентноеЗадание, запускается не более 1 раза. Если заданий много, то они запускаются не все одновременно, а с небольшим смещением во времени.

После перезапуска процесса менеджера кластера, первый запуск регламентных заданий пассивной информационной базы выполняется через случайный интервал времени после запуска менеджера кластера. Величина интервала составляет от 60 секунд (минимальная задержка запуска) по значения 60 + Максимальный сдвиг запуска регламентных заданий секунд (максимальная задержка запуска).

При переходе информационной базы из активного состояния в пассивное состояние, интервал времени Минимальный период запуска регламентных заданий отсчитывается с момента запуска последнего регламентного задания в активной базе.

При переходе информационной базы из пассивного состояния в активное, все регламентные задания, которые ожидают своего запуска в рамках интервала Минимальный период запуска регламентных заданий, выполняются вместе с очередным запуском регламентного задания по расписанию, но не позднее чем через 20 секунд после того, как информационная база стала активной. Если заданий много, то они запускаются не все одновременно, а с небольшим смещением во времени.

Рассмотрим пример, в рамках которого в информационной базе существуют два регламентных задания:

● Первое задание: расписание настроено на запуск 1 раз в 2 часа, старт в 00:00.

● Второе задание: расписание настроено на запуск 1 раз в 24 часа, старт в 01:00.

Кластер настроен следующим образом:

● Минимальный период запуска регламентных заданий: 3 часа (10 800 секунд).

● Максимальный сдвиг запуска регламентных заданий: 1 час (3 600 секунд).

График запуска регламентных заданий для активной информационной базы:

● Первое задание:

● Сутки 1: 0:00, 02:00, 04:00, 06:00, 08:00, 10:00, 12:00, … , 20:00, 22:00.

● Сутки 2: 00:00, 02:00, 04:00 и т. д.

● Второе задание:

● Сутки 1: 01:00.

● Сутки 2: 01:00 и т. д.

В 0:30 информационной база перешла в состояние пассивная.

График запуска регламентных заданий для пассивной информационной базы:

● Первое задание:

● Сутки 1: 03:30, 06:30, 09:30, 12:30, 15:30, 18:30, 21:30.

● Сутки 2: 00:30, 03:30, 06:30 и т. д.

● Второе задание:

● Сутки 1: 03:30.

● Сутки 2: 03:30 и т. д.

Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.

Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.

Требование назначения функциональности определяет:

● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. здесь), клиентские соединения (см. здесь) и произвольный объект требования. В качестве объекта требования могут выступать сервисы кластера, для которых отмечена возможность переноса (подробнее см. здесь).

● Определяет тип требования. Тип требования определяет, каким образом будет выполняться использование рабочего сервера:

● Не назначать ‑ означает, что рабочий сервер, для которого создано данное требование, не будет назначен для обслуживания объекта требования, подходящего под условия, заданные в требовании.

● Назначать ‑ означает, что рабочий сервер, для которого создано данное требование, будет являться одним из кандидатов на обслуживание данного объекта требования (если рабочих серверов будет несколько).

● Авто ‑ означает, что рабочий сервер может быть использован для обслуживания объекта требования в том случае, если нет рабочего сервера с явным указанием необходимости использования.

● Дополнительные параметры, необходимые кластеру серверов для принятия решения в ряде случаев:

● Имя ИБ. Используется для уточнения требования для формирования требований для клиентских соединений и всех сервисов кластера, которые могут выступать в качестве объекта требования, кроме сервиса лицензирования. Необходимо помнить, что имя информационной базы является регистронезависимым.

● Значение дополнительного параметра. Используется для уточнения требований при размещении клиентского соединения или сервиса сеансовых данных. При размещении клиентского соединения, нового сеанса в сервисе сеансовых данных или сервиса Дата акселератора, размещаемый объект имеет дополнительный параметр. Дополнительный параметр состоит из одного или нескольких слов, разделённых символом «.». Сравнение значения дополнительного параметра требования со значением дополнительного параметра объекта размещения выполняется по словам, слева-направо. Дополнительный параметр объекта размещения соответствует дополнительному параметру требования в том случае, если все слова в дополнительном параметре требования совпали с соответствующими словами дополнительного параметра объекта размещения. Пустое значение дополнительного параметра требования соответствует любому значению дополнительного параметра объекта размещения.

Дополнительный параметр объекта размещения может принимать одно из следующих значений:

● Размещение нового сеанса в сервисе сеансовых данных:

● Конфигуратор: Designer.

● Толстый клиент: 1CV8.

● Тонкий клиент: 1CV8C.

● Тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»: 1CV8CDirect.

● Веб-клиент: WebClient.

● COM-соединение: COMConnection.

● Вызов Web-сервиса: WSConnection.

● Вызов HTTP-сервиса: HTTPServiceConnection.

● Вызов стандартного интерфейса OData: ODataConnection.

● Бот системы взаимодействия: BotConnection.

● Мобильный клиент: MobileClient.

● Клиент системы «1С:Аналитика»: AnalyticsSystemClient.

● Запрос системы 1С:Аналитика: AnalyticsSystemQuery.

● Системное фоновое задание: SystemBackgroundJob:

● Предварительная загрузка контекста информационной базы.

● Фоновая реструктуризация.

● Пересчет итогов.

● Фоновое задание, исполняющее метод встроенного языка: <Имя общего модуля>.<Имя метода>.

● Другое фоновое задание: BackgroundJob.

● Размещение клиентского соединения:

● Конфигуратор: Designer.

● Толстый клиент: 1CV8.

● Тонкий клиент: 1CV8C.

● Тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»: 1CV8CDirect.

● COM-соединение: COMConnection.

● Соединение с информационной базой через веб-сервер (веб-клиент, тонкий клиент в случае подключения через веб-сервер, мобильный клиент, Интернет-сервис): WebServerExtension.

● Соединение пользователя информационной базы: UserName.<Имя>.

● Соединение пользователя, у которого свойство Ключ требования назначения установлено в некоторое значения: UserAssignmentRuleKey.<Значение>.

● Фоновое задание, запущенное из встроенного языка: BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>.

● Регламентное задание: BackgroundJob.ScheduledJob.<Имя объекта конфигурации>.

● Другие фоновые задания:

● Индексация полнотекстового поиска: BackgroundJob.FullTextSearchIndexUpdate.

● Построение отчёта (включая внешний отчет): BackgroundJob.GenerateReport.<Полное имя объекта конфигурации>.

● Ввод по строке: BackgroundJob.InputByString.<Полное имя объекта конфигурации>.

● Поиск в списке: BackgroundJob.DynamicListSearch.<Полное имя формы>.<Имя таблицы формы связанной со списком>.

● Первоначальное заполнение копии базы данных: BackgroundJob.DBCopiesFilling.

● Обновление копий базы данных: BackgroundJob.DBCopiesNotification.

● Обновление истории данных сразу после записи версионируемого объекта: BackgroundJob.UpdateDataHistoryImmediatelyAfterWrite.

● Обработка после записи версий: BackgroundJob.AfterWriteDataHistoryVersionsProcessing.

● Механизм глобального поиска по:

● меню функций: BackgroundJob.GlobalSearchFunctionsMenu;

● данным: BackgroundJob.GlobalSearchFullTextSearch;

● справке: BackgroundJob.GlobalSearchHelp;

● метаданным: BackgroundJob.GlobalSearchAllFunctions.

● Фоновое задание, вызывающее в фоновом режиме процедуру поиска, реализованную на встроенном языке и указанную в плане глобального поиска: BackgroundJob.GlobalSearch.<имя модуля>.<имя метода>.

● Используемые сервисом интеграции для:

● Обработки очереди отправки сообщений: BackgroundJob.SendIntegrationSystemMessagesQueueProcessing.<полное имя сервиса интеграции>.

● Обработки очереди получения сообщений: BackgroundJob.ReceiveIntegrationSystemMessagesQueueProcessing.<полное имя сервиса интеграции>.

● Получения сообщений: BackgroundJob.ReceivingIntegrationSystemMessages.<полное имя сервиса интеграции>.

● Обработки полученных сообщений: BackgroundJob.ReceivedIntegrationSystemMessagesProcessing.<полное имя канала сервиса интеграции>.

● Работа с автономной информационной базой (создание новых узлов, подготовка к обмену, обмен, удаление неиспользуемых узлов): BackgroundJob.StandaloneExchange.

● Системные фоновые задания:

● Обработка оповещений копий базы данных: SystemBackgroundJob.DBCopiesNotification.

● Фоновая реструктуризация: SystemBackgroundJob.DBConfigUpdate.

● Фоновое задание пересчета итогов: SystemBackgroundJob.RecalcTotals.

● Формирование события журнала регистрации изменения параметров информационной базы: SystemBackgroundJob.InfoBaseAdministrationParametersChange.

● Формирование события журнала регистрации изменения профиля безопасности информационной базы: SystemBackgroundJob.InfoBaseSecurityProfileChange.

● Размещение сервиса Дата акселератора:

● Дополнительный параметр может содержать имя копии базы данных со встроенным Дата акселератором. В этом случае на выбранном рабочем сервере будет обслуживаться только копия с указанным именем. На одном рабочем сервере можно обслуживать несколько копий со встроенным Дата акселератором. В информационной базе управление копиями базы данных осуществляется с помощью стандартной функции Управление копиями базы данных.

После того, как созданы необходимые требование назначения функциональности, их необходимо применить. Для этого следует воспользоваться консолью администрирования кластера (см. здесь).

Рассмотрим, как работает кластер серверов при обработке требований. В случае необходимости выполнить размещение объекта требования, кластер выполняет следующие действия:

● На всех серверах, входящих в состав кластера, выполняется обработка заданных для этих серверов требований назначения функциональности. Обход серверов и требований выполняется в порядке следования этих объектов в консоли кластера.

● В каждом списке требований определяется первое требование, которое удовлетворяет размещаемому объекту: по собственно объекту, информационной базе и дополнительному параметру.

● Затем полученный список рабочих серверов сортируется по признаку типа требования так, что первыми оказываются рабочие сервера с явным указанием использования. Рабочие сервера, для которых подходящее требование содержит явный запрет на использование ‑ исключаются из списка доступных рабочих серверов. При этом назначение выполняется следующим образом:

● Есть рабочие сервера с явным указанием использования: в этом случае объект требования будет обслужен одним из этих рабочих серверов.

● Нет рабочих серверов с явным указанием использования: происходит попытка использовать рабочие сервера с автоматическим указанием использования или те рабочие серверы, для которых не указано требований.

● Подробное описание правил выбора рабочего сервера для обслуживания объекта требования см. здесь.

● При размещении клиентского соединения, из списка доступных серверов будет выбран тот, в состав которого входит рабочий процесс с наивысшей доступной производительностью (см. здесь). Подробное описание правил выбора рабочего процесса в конкретном рабочем сервере см. здесь.

Клиентское приложение, инициировавшее размещение объекта требования, будет завершено аварийно в одном из следующих случаях:

● Если для объекта требования список рабочих серверов оказывается пустым ‑ нет ни одного рабочего сервера, который может обслужить объект. При этом объект требования не будет размещен и будет вызвано исключение.

● Если невозможно выполнить размещение на выбранном рабочем сервер, например, если выбранный сервер вышел из строя, и нет альтернативных рабочих серверов.

Более подробно рассмотрим алгоритм назначения рабочего сервера для обслуживания сервиса кластера.

Для сервисов кластера (см. здесь) объектом требования может выступать:

● Сервис одного типа, если сервис не делится по информационным базам.

● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.

● Сервис сеансовых данных.

● Сервис лицензирования.

Сервисы распределяются между подходящими рабочими серверами следующим образом:

● Из списка рабочих серверов, выбранных для размещения сервиса в соответствии с требованиями назначения функциональности, отбираются те, которые в данный момент работоспособны. Из них выбираются те рабочие серверы, у которых свойство Приоритет содержит максимальное значение. Если работоспособных рабочих серверов нет, то попытка размещения сервиса приводит к ошибке.

● Среди отобранных рабочих серверов сервисы распределяются равномерно.

● Сервисы, поддерживающие репликацию, могут назначаться на несколько рабочих серверов. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь). При этом один сервис будет являться активным, а с другими сервисами (резервными) будет поддерживаться репликация служебных данных сервиса. Репликация выполняется асинхронно. Синхронизация выполняется каждую секунду.

● Сервисы, которые не поддерживают перенос (характеристика Не переносится, подробнее см. здесь), назначаются на все рабочие серверы кластера с установленным флажком Центральный сервер (см. здесь).

● Для каждого сеанса, который обслуживает кластер серверов, создается свой экземпляр сервиса сеансовых данных. При отборе рабочих серверов, которые могут обслужить данный экземпляр сервиса, учитываются дополнительные параметры требования. Из списка доступных выбираются сервера с минимальным количеством обслуживаемых сервисов кластера. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь).

● В случае необходимости использования сервиса лицензирования следует явно выбрать рабочий сервер, к которому будет выполняться привязка программной лицензии и явно описать в требованиях размещение сервиса на выбранном рабочем сервере.

● Остальные сервисы назначаются в единственном экземпляре.

Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:

● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.

● При удалении рабочего сервера из состава кластера или недоступности рабочего сервера выполняется переназначение только тех объектов требований, которые обслуживал удаляемый рабочий сервер. Данное переназначение выполняется автоматически.

● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.

● Переназначение происходит также в том случае, если администратор кластера выполнит операцию полного или частичного применения требований из консоли кластера (см. здесь).

При запуске кластера на каждом рабочем сервере запускается по одному рабочему процессу и начинается процесс вычисления доступной производительности для каждого рабочего сервера (см. здесь).

Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:

● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.

Ограничения по использованию оперативной памяти учитываются в том случае, если запрос на установку соединения выполняется к информационной базе, к которой нет установленных соединений на выбранном рабочем сервере. В случае превышения лимита использования оперативной памяти рабочий сервер исключается из списка, если существует другой рабочий сервер, который не превысил лимит. Также исключаются рабочие сервера, которые не могут обработать требуемое соединение исходя из требований назначения.

● Для выбранного сервера определяется список рабочих процессов, которые доступны и могут обслужить запрашиваемое соединение. Рабочий процесс относится к списку доступных рабочих процессов в следующих случаях:

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс).

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера Количество соединений на процесс).

● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.

● Из выбранных рабочих процессов предпочтение отдается тем рабочим процессам, которые уже обслуживают соединения информационной базы, соединение с которой необходимо обслужить. Если такого рабочего процесса нет ‑ выбирается рабочий процесс с максимальным количеством обслуживаемых соединений.

● Если не удалось выбрать ни один рабочий процесс, то на данном рабочем сервере запускается новый рабочий процесс, который и будет обслуживать запрошенное соединение.

При установке соединения от лица существующего сеанса (если не удалось повторно использовать соединение предыдущего вызова сервера) предпочтение отдается рабочему процессу, который обслуживал предыдущее соединение этого сеанса. При этом возможен выбор другого рабочего процесса, если доступная производительность другого рабочего процесса выше доступной производительности текущего рабочего процесса не менее чем на 25%.

Если на одном рабочем сервере в течение 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.

При подсчете количества обслуживаемых соединений учитываются соединения, которые создаются отладчиком для проверки прав доступа на предмет отладки.

При рассмотрении примеров требований назначений функциональности будет использоваться следующий кластер серверов:

Рис. 10. Кластер для примеров требований

Кластер обладает следующими характеристиками:

● Количество рабочих серверов: 3.

● Уровень отказоустойчивости: 1.

● Количество центральных серверов: 2 (SRV1, SRV2).

● Операционные системы на рабочих серверах:

● Сервер SRV1, ОС Windows.

● Сервер SRV2, ОС Linux.

● Сервер SRV3, ОС Windows.

Кластер обслуживает следующие информационные базы:

● DemoDB,

● WorkDB.

Если необходимо разместить все фоновые задания на рабочем сервере SRV1, то для этого необходимо для рабочего сервера SRV1 задать следующее требование назначения функциональности:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.

Необходимо многопользовательскую клиентскую лицензию активировать для компьютера, на котором функционирует рабочий сервер SRV2, разместить на этот компьютер сервис лицензирования и не размещать на этот компьютер больше никаких сервисов. Тогда для рабочего сервера SRV2 следует указать следующие требования:

● Требование 1:

● Объект требования: Сервис лицензирования.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

● Требование 2:

● Объект требования: Любой объект требования.

● Тип требования: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRV2, а Требование 2 обеспечит функционирование на сервере SRV2 только сервиса лицензирования (на сервере SRV2 не будут функционировать другие сервисы кластера).

При активации программной лицензии с помощью сервера «1С:Предприятия» следует указывать имя SRV2, в противном случае активированная лицензия не сможет быть использована кластером серверов, т. к. программная лицензия будет активирована для другого компьютера.

Необходимо разрешить работу сервиса работы с внешними источниками данных на рабочих серверах SRV1 и SRV3, и запретить ‑ на рабочем сервере SRV2. Для этого следует для рабочего сервера SRV2 указать следующее требование:

● Объект требования: Сервис работы с внешними источниками данных.

● Тип требования: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

Необходимо настроить кластер серверов таким образом, чтобы каждая информационная база обслуживалась одним рабочим процессом. Для этого необходимо для каждого рабочего сервера установить свойство Количество ИБ на процесс в значение 1.

В результате на каждом сервере будет создано по два рабочих процесса (всего ‑ 6, по 2 рабочих процесса на каждый из 3 рабочих серверов). При этом обслуживанием одной информационной базы будет заниматься 3 рабочих процесса на 3 рабочих серверах.

Необходимо настроить кластер серверов таким образом, чтобы информационную базу DemoDB обслуживал только рабочий сервер SRV3, а информационную базу WorkDB обслуживали оба рабочих сервера: SRV1 и SRV2. Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV3:

● Объект требования: Любой объект требования.

● Тип требования: Назначать.

● Имя ИБ: DemoDB.

● Значение дополнительного параметра: не указывается.

● Для рабочих серверов SRV1 и SRV2:

● Объект требования: Любой объект требования.

● Тип требования: Назначать.

● Имя ИБ: WorkDB.

● Значение дополнительного параметра: не указывается.

Указанные правила «разнесут» по рабочим серверам все механизмы кластера серверов: соединения, фоновые задания, сервисы сеансовых данных и т. д.

Необходимо настроить кластер серверов таким образом, чтобы на рабочем сервере SRV1 выполнялись только отчеты, на рабочем сервере SRV2 выполнялись только регламентные задания ОбновлениеИндексаППД и ОбновлениеАгрегатовПродаж, а остальные фоновые задания должны выполняться на рабочем сервере SRV3. Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV1:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.GenerateReport.

● Для рабочего сервера SRV2:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.РаботаСПолнотекстовымПоиском.ОбновлениеИндексаПолнотекстовогоПоиска.

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.РегламентныеЗаданияАгрегатов.ОбновлениеАгрегатовПродаж.

Требуется настроить кластер таким образом, чтобы рабочий сервер SRV1 обслуживал все фоновые задания, которые стартуют из общего модуля СервисныеЗаданияСервер, а сервер SRV2 должен обслуживать только поиск в динамических списках.

Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV1:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.СервисныеЗаданияСервер.

● Для рабочего сервера SRV2:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.DynamicListSearch.

Если требуется запретить использование Дата акселератора во всем кластере, то необходимо выполнить следующие действия:

● На любом рабочем сервере создать два требования в приведенном порядке (порядок расположения требований важен):

● Требование 1:

● Объект требований: Любой объект требований.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

● Требование 2:

● Объект требований: Сервис Дата акселератора.

● Тип требований: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

● На каждом из оставшихся рабочих серверах:

● Требование 3:

● Объект требований: Сервис Дата акселератора.

● Тип требований: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

Если кластер серверов состоит из одного рабочего сервера, то необходимо создать первые два требования в указанном порядке. Создание одного правила (с типом требования Не назначать) будет невозможно применить из-за особенности функционирования механизма требований.

Требуется настроить кластер таким образом, чтобы рабочий сервер SRV1 обслуживал все сеансы пользователя с именем ВнешнийСервис (от имени которого, например, выполняются все HTTP- и Web-сервисы для внешнего доступа к данным информационной базы), а сервер SRV2 должен обслуживать только пользователей, для которых Ключ требования назначения установлен в значение Аналитики.

Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV1:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: UserName.ВнешнийСервис.

● Для рабочего сервера SRV2:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: UserAssignmentRuleKey.Аналитики.

Если вышеуказанные правила необходимо применить только для одной информационной базы, в вышеприведенных правилах следует заполнить поле Имя ИБ. В это поле нужно вписать имя информационной базы, для которой будут выполняться данные правила распределения соединений с кластером серверов.

Следует учитывать, что Значение дополнительного параметра может быть или единственным значением UserName.<имя> или единственным значением UserAssignmentRuleKey.<имя>. Комбинация значений, регулярные выражения и прочие способы указать множественные результаты параметра ‑ не поддерживаются.

Работающее прикладное решение может использовать для своих нужд различные внешние ресурсы: каталоги файловой системы, COM-объекты (на Windows-системах), внешние компоненты, приложения ОС и т. д. Однако, по соображениям безопасности, для различных прикладных решений могут быть доступны не все возможные внешние ресурсы, а только ограниченное их подмножество. Может потребоваться создать собственный каталог временных файлов для каждой области разделенной информационной базы или задать перечень ресурсов сети Интернет, к которым может иметь доступ прикладное решение.

Чтобы установить такие ограничения, для кластера серверов можно настроить профили безопасности. Профиль безопасности ‑ это набор явно заданных разрешений на использование тех или иных внешних ресурсов (с указанием перечня таких ресурсов), которые можно назначать информационным базам, зарегистрированным в кластере. Профили безопасности создаются администратором кластера и позволяют настраивать следующие разрешения:

● Возможность использования данного профиля в качестве профиля безопасности безопасного режима ‑ если это разрешение установлено (свойство профиля Может использоваться как профиль безопасности безопасного режима), то имя данного профиля безопасности можно указывать во встроенном языке при включении безопасного режима и подключении внешних отчетов и обработок.

● Доступные ресурсы файловой системы сервера (см. здесь).

● Доступные COM-объекты (только для серверов, работающих под управлением ОС Windows) (см. здесь).

● Доступные внешние компоненты (см. здесь).

● Внешние модули (внешние отчеты; внешние обработки; расширения конфигурации; код, исполняемый оператором Выполнить() и функцией Вычислить()), исполнение которых возможно в небезопасном режиме (см. здесь).

● Доступные приложения операционной системы (см. здесь).

● Доступные ресурсы сети Интернет (см. здесь).

● Возможность доступа к привилегированному режиму ‑ если данное разрешение установлено (свойство профиля Разрешен полный доступ: к привилегированному режиму), то при использовании данного профиля разрешено включать привилегированный режим (см. здесь).

● Возможность доступа к функциям криптографии (см. здесь).

● Возможность расширения прав доступа (см. здесь).

● Возможность расширения всех модулей конфигурации (см. здесь).

Для того чтобы информационная база использовала для работы созданный профиль безопасности, следует указать его имя в свойствах информационной базы (с помощью средств администрирования кластера серверов). Также в свойствах информационной базы можно указать имя профиля, который будет использоваться при установке в прикладном решении безопасного режима.

Некоторые разрешения позволяют задавать список разрешенных ресурсов. Это разрешения:

● Доступные ресурсы файловой системы сервера;

● Доступные COM-объекты (только для серверов, работающих под управлением ОС Windows);

● Доступные внешние компоненты;

● Доступные внешние модули;

● Доступные приложения операционной системы;

● Доступные ресурсы сети Интернет;

● Возможность расширения прав доступа;

● Возможность расширения всех модулей конфигурации.

В этом случае работа осуществляется следующим образом:

● Если в профиле безопасности флажок сброшен (например, доступ к ресурсам сети Интернет), то из информационной базы, для которой указан данный профиль безопасности, невозможно использовать ни одного ресурса сети Интернет.

● Если в профиле безопасности этот флажок установлен, то прикладное решение обладает полным доступом к ресурсам сети Интернет.

● Если требуется предоставить ограниченный доступ (по списку), то следует отключить флажок и задать список ресурсов, доступ к которым разрешен. Для некоторых разрешений возможно указание как списка разрешенных, так и списка запрещенных ресурсов. Для каждого разрешения список ограничений может формироваться особым образом.

Описание конкретных разрешений будет приведено далее.

Для доступа к файловым ресурсам сервера применяются виртуальные каталоги. Это означает, что в рамках профиля безопасности существует некоторая виртуальная файловая система, в которой создаются каталоги. Каждый виртуальный каталог имеет отражение на реальную файловую систему по определенным правилам. В тот момент, когда прикладному решению необходимо выполнить файловую операцию, в параметре соответствующей функции указывается путь к файлу, расположенному в виртуальной файловой системе. «1С:Предприятие» транслирует виртуальный каталог в реальный и формирует реальный путь к файлу, с которым и выполняется реальная работа. Прикладное решение не может получить информацию о том, в какой физический путь будет отражен виртуальный каталог.

Если в профиле безопасности указаны несколько виртуальных каталогов, то прикладное решение может осуществлять доступ только к этим ресурсам. Попытка доступа к любому другому каталогу (как реальному, так и виртуальному) ‑ невозможна.

Виртуальные каталоги используются при обращении к методам встроенного языка:

● Глобальный контекст:

● КаталогПрограммы(),

● КаталогВременныхФайлов(),

● ЗначениеВФайл(),

● ЗначениеИзФайла(),

● КопироватьФайл(),

● ПереместитьФайл(),

● УдалитьФайлы(),

● НайтиФайлы(),

● СоздатьКаталог(),

● РазделитьФайл(),

● ОбъединитьФайлы(),

● ПолучитьИмяВременногоФайла().

● Объект Картинка:

● конструктор на основании имени файла,

● Записать().

● Объект ДвоичныеДанные:

● конструктор на основании имени файла,

● Записать().

● Объект ИзвлечениеТекста:

● конструктор на основании имени файла,

● изменение свойства ИмяФайла,

● Записать().

● Объект ТекстовыйДокумент:

● Записать(),

● Прочитать().

● Объект ТабличныйДокумент:

● Записать(),

● Прочитать().

● Объект ФорматированныйДокумент:

● Записать().

● Объект ГрафическаяСхема:

● Записать(),

● Прочитать().

● Объект ГеографическаяСхема:

● Записать(),

● Прочитать().

● Объект Файл:

● конструктор на основании имени файла.

● Объект xBase:

● конструктор на основании имени файла.

● ОткрытьФайл(),

● СоздатьИндексныйФайл(),

● СоздатьФайл().

● Объект ЧтениеXML:

● ОткрытьФайл().

● Объект ЗаписьXML:

● ОткрытьФайл().

● Объект КаноническаяЗаписьXML:

● ОткрытьФайл().

● Объект ПреобразованиеXSL:

● ЗагрузитьИзФайла(),

● ПреобразоватьИзФайла().

● Объект ЧтениеFastInfoset:

● ОткрытьФайл().

● Объект ЗаписьFastInfoset:

● ОткрытьФайл().

● Объект ЗаписьZipФайла:

● конструктор на основании имени файла,

● Добавить(),

● Открыть().

● Объект ЧтениеZipФайла:

● конструктор на основании имени файла,

● Извлечь(),

● ИзвлечьВсе(),

● Открыть().

● Объект СертификатКлиентаФайл:

● конструктор по умолчанию.

● Объект СертификатыУдостоверяющихЦентровФайл:

● конструктор по умолчанию.

● Объект ЗаписьHTML:

● ОткрытьФайл().

● Объект ЧтениеHTML:

● ОткрытьФайл().

● Объект ЧтениеТекста:

● конструктор на основании имени файла,

● Открыть().

● Объект ЗаписьТекста:

● конструктор на основании имени файла,

● Открыть().

● Объект СертификатКриптографии:

● конструктор на основании имени файла.

● Объект МенеджерКриптографии:

● Подписать(),

● ПроверитьПодпись(),

● Зашифровать(),

● Расшифровать(),

● ПолучитьСертификатыИзПодписи().

● Объект ХешированиеДанных:

● ДобавитьФайл().

Виртуальный каталог описывается несколькими параметрами:

● Логический URL ‑ адрес, который будет использоваться прикладным решением. Этот параметр должен выглядеть как начало реального пути в соответствующей файловой системе (для ОС Windows или Linux). Пути, которые используются в прикладном решении, могут начинаться только со значения, которое в точности совпадает со значением логического URL. Например, если в качестве логического URL указана строка \storage, то при указании в прикладном решении пути \storage\document.txt будет использован этот виртуальный каталог, а при указании пути storage\document.txt ‑ не будет. Значение логического URL является уникальным в рамках одного профиля.

Существуют два предопределенных логических URL, которые используются методами системы:

● /bin ‑ каталог загрузочных модулей текущей версии «1С:Предприятия». Этот виртуальный каталог используется методом КаталогПрограммы().

● /temp ‑ каталог временных файлов. Этот виртуальный каталог используется методом КаталогВременныхФайлов().

● Физический URL ‑ адрес, указывающий физическое размещение логического URL в файловой системе сервера. Может включать специальные подстановочные символы. В процессе выполнения файловой операции «1С:Предприятие» преобразует логический URL в реальный адрес файловой системы заменой всех подстановочных символов. При этом каждая последовательность символов, не допустимых в URL, заменяется на символ "_".

В адресе можно использовать следующие подстановочные символы:

● %r ‑ ссылочное имя информационной базы;

● %i ‑ идентификатор информационной базы;

● %z ‑ строковое представление текущих значений разделителей текущего сеанса в формате, принятом для параметра командной строки /Z.

● %s ‑ номер сеанса;

● %c ‑ номер соединения;

● %p ‑ идентификатор безопасного режима исполнения прикладного кода;

● %e ‑ каталог загрузочных модулей «1С:Предприятия»;

● %t ‑ текущий каталог временных файлов операционной системы;

● %u ‑ каталог данных приложений текущего пользователя;

● %a ‑ каталог данных приложений всех пользователей;

● %n ‑ имя текущего пользователя информационной базы;

● %% ‑ символ %.

● Разрешено чтение данных ‑ флажок определяет, допустимо или нет чтение файлов из данного виртуального каталога.

● Разрешена запись данных ‑ флажок определяет, допустима или нет запись файлов в данном виртуальном каталоге.

При указании физически URL возможно указание как на собственные каталоги компьютера, на котором установлено «1С:Предприятие» и на сетевые ресурсы. При этом надо учитывать особенности организации файловых систем и работы с сетевыми ресурсами той операционной системы, на которой функционирует сервер.

При завершении сеанса удаляются физические каталоги, в определении которых участвовал символ подстановки %s. При завершении соединения удаляются физические каталоги, в определении которых участвовал символ подстановки %с. Вход в безопасный режим исполнения кода на встроенном языке обладает собственным уникальным идентификатором. При выходе из безопасного режима удаляются физические каталоги, в определении которых участвовал символ подстановки %p.

Профиль безопасности кластера может содержать список классов COM-объектов, которые можно использовать в прикладном решении.

Если информационная база ссылается на профиль безопасности, в котором ограничено использование COM-объектов, то возможно использование только тех классов COM-объектов, которые перечислены в списке разрешенных COM-классов этого профиля. Используемый конфигурацией COM-объект соответствует элементу списка разрешенных COM-объектов профиля безопасности, если совпадает значение свойства Компьютер COM-объекта и совпадают отличные от пустых значения свойства Файл (моникер) и Идентификатор COM-класса. При попытке создания экземпляра любого COM-объекта, отсутствующего в списке, будет выдано исключение.

Разрешенный класс COM-объекта описывается следующими параметрами:

● Имя ‑ уникальное имя класса COM-объекта. Является уникальным в рамках одного профиля.

● Файл (моникер) ‑ имя файла-моникера. Используется при вызове метода ПолучитьCOMОбъект() с неуказанным значением параметра ИмяКлассаCOM. Подробнее про файл-моникер можно прочитать по адресу: http://msdn.Microsoft.com/ru-RU/library/windows/desktop/ms688670(v=vs.85).aspx (на английском языке).

● Идентификатор COM-класса ‑ строка, представляющая собой идентификатор класса COM-объекта, в формате реестра ОС Windows, без обрамляющих фигурных скобок. Данное значение используется в конструкторе нового COM-объекта и методе ПолучитьCOMОбъект().

● Компьютер COM-объекта ‑ компьютер, на котором может быть создан COM-объект. Используется конструктором нового COM-объекта. Для указания текущего компьютера следует использовать строку localhost, пустая строка означает, что COM-объект может создаваться на любом компьютере.

Профиль безопасности кластера может содержать список внешних компонент, которые можно использовать в прикладном решении. Если информационная база ссылается на профиль безопасности, в котором ограничено использование внешних компонент, то возможно использование только тех внешних компонент, которые перечислены в списке разрешенных внешних компонент этого профиля. При попытке выполнения метода ПодключитьВнешнююКомпоненту() для компоненты, отсутствующей в списке, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие внешние компоненты.

Разрешенная внешняя компонента описывается следующими параметрами:

● Имя ‑ уникальное имя внешней компоненты. Является уникальным в рамках одного профиля.

● Контрольная сумма ‑ контрольная сумма SHA1 разрешенной внешней компоненты, преобразованная к формату base64.

Для построения контрольной суммы можно использовать объект ХешированиеДанных и метод глобального контекста Base64Строка().

Если оформляется разрешение для внешней компоненты, разработанной по технологии Native API, то для каждого, поддерживаемого компонентой, типа платформы необходимо задавать отдельное разрешение. Таким образом, внешняя компонента, поддерживающая все платформы, будет иметь 4 разрешения: для 32‑ и 64-разрядной ОС Windows и для 32‑ и 64-разрядной ОС Linux.

Профиль безопасности кластера может содержать список внешних модулей, которые можно использовать из кода прикладного решения без включения безопасного режима. Под внешними модулями понимаются: внешние отчеты и обработки, а также расширения конфигурации. Если информационная база ссылается на профиль безопасности, в котором ограничено использование внешних модулей, то возможно использование без включения безопасного режима только тех внешних модулей, которые перечислены в этом списке. При попытке использования внешнего модуля, не содержащегося в этом списке, без включения безопасного режима, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие внешние модули без включения безопасного режима. Также с помощью данного элемента профиля управляется возможность использования оператора Выполнить() и функции Вычислить() в безопасном режиме. Если в профиле безопасности флажок Разрешен полный доступ: к внешним модулям сброшен, то в прикладном решении можно использовать Выполнить() и Вычислить() только в безопасном режиме (явно устанавливая его перед использованием оператора или функции). Если прикладное решение использует Выполнить() и Вычислить() в технологических целях (в небезопасном режиме), то для него нельзя использовать профиль безопасности, у которого сброшен флажок Разрешен полный доступ: к внешним модулям.

Разрешенный внешний отчет или обработка описывается следующими параметрами:

● Имя ‑ уникальное имя внешнего модуля. Является уникальным в рамках одного профиля.

● Контрольная сумма ‑ контрольная сумма SHA1 разрешенного внешнего отчета или обработки, преобразованная к формату base64.

Для построения контрольной суммы можно использовать объект ХешированиеДанных и метод глобального контекста Base64Строка(). Для расширения конфигурации контрольную сумму можно получить или с помощью программного интерфейса, или с помощью Конфигуратора (команда главное меню ‑ Конфигурация ‑ Расширения конфигурации ‑ Действия ‑ Показать контрольную сумму).

Профиль безопасности кластера может содержать список приложений, которые можно запускать из прикладного решения. Если информационная база ссылается на профиль безопасности, в котором ограничен запуск приложений, то возможно использование только тех приложений (исполняемых файлов), которые перечислены в списке разрешенных приложений этого профиля. При попытке выполнения метода ЗапуститьПриложение() с приложением или параметрами, которым не соответствует ни одной записи в списке, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие приложения.

Разрешенное приложение операционной системы описывается следующими параметрами:

● Имя ‑ имя приложения. Уникально в пределах профиля безопасности.

● Шаблон строки запуска ‑ шаблон строки запуска приложения. Состоит из последовательности шаблонных слов, разделенных пробелами. Шаблонное слово представляет собой произвольную последовательность символов и может содержать символы подстановки. Если шаблонное слово может содержать пробелы, то оно должно быть заключено в кавычки.

Символы подстановки:

● % ‑ произвольная последовательность символов;

● _ ‑ один произвольный символ;

● * ‑ имя файла. Если шаблонное слово начинается с символа *, то параметр является маршрутом от виртуального каталога. Перед выполнением виртуальный каталог заменяется на реальный каталог.

● \ ‑ префикс символа. Указание данного символа перед шаблонным словом делает слово не шаблонным.

Проверка соответствия запускаемого приложения списку разрешенных приложений выполняется для имени запускаемого приложения и каждого из параметров, имеющихся в команде запуска. Отсутствие соответствующего шаблонного слова значит, что шаблон не соответствует строке запуска.

Например, шаблон xcopy */temp/% */userdata/% позволяет выполнять копирование произвольного файла из виртуального каталога /temp в виртуальный каталог /userdata.

В строке запуска параметры разделяются одним или несколькими пробелами.

Строка, заключенная в кавычки ("), является одним параметром. Одним параметром считается последовательность слов, если первое и последнее слово содержит нечетное количество одиночных символов кавычки. Если есть первое слово с кавычками, но нет второго, то одним параметром считается все до конца строки. Если параметр не заключен в кавычки, то символ кавычки представляется парой символов \". Символ кавычки в составе параметра, заключенного в кавычки, может представляться одной из пар символов: \" или "".

Профиль безопасности может содержать список ресурсов интернет, к которым разрешены обращения из серверного кода прикладного решения. Если в профиле безопасности ограничено использование интернет, то использование объекта ИнтернетСоединение запрещено, а при помощи объектов ИнтернетПочта, HTTPСоединение, FTPСоединение, WSОпределения разрешено обращение только к тем ресурсам, которые перечислены в списке разрешенных ресурсов интернет этого профиля. При обращении к другим ресурсам будет порождено исключение. Пустой список значит, что запрещено обращение к любым ресурсам интернет.

Разрешенный ресурс сети Интернет описывается следующими параметрами:

● Имя ‑ имя ресурса для его идентификации. Уникально в пределах профиля безопасности.

● Адрес ‑ адрес ресурса без указания протокола.

● Порт ‑ номер порта, через который выполняется взаимодействие с указанным ресурсом. При указании значения 0 допускается использование любого порта для взаимодействия.

● Тип ресурса (протокол) ‑ протокол, по которому выполняется взаимодействие с ресурсом. Могут быть указаны следующие протоколы (регистр символов не играет роли):

● imap ‑ сервер электронной почты, работающий по протоколу IMAP.

● pop3 ‑ сервер электронной почты, работающий по протоколу POP3.

● smtp ‑ сервер электронной почты, работающий по протоколу SMTP.

● http ‑ веб-сервер.

● https ‑ защищенное соединение с веб-сервером.

● ftp ‑ ftp-сервер.

● ftps ‑ защищенное соединение с ftp-сервером.

Если сеанс работает в безопасном режиме под управлением профиля безопасности, то работа привилегированного режима зависит от двух параметров профиля безопасности: флажок к привилегированному режиму группы Разрешен полный доступ и свойство Роли привилегированного режима.

Если флажок к привилегированному режиму установлен, то при включении привилегированного режима ‑ привилегированный режим включается в полном объеме: отключается контроль прав и ограничения доступа к данным.

Если флажок к привилегированному режиму сброшен, то поведение системы определяется состояние свойства Роли привилегированного режима:

● В свойстве указаны какие-либо роли. В этом случае при включении привилегированного режима в текущем сеансе устанавливаются права доступа (и ограничения доступа к данным) тех ролей, которые указаны в свойстве Роли привилегированного режима. При выключении привилегированного режима (любым способом) возвращается действие тех ролей и ограничений доступа к данным, которые были до включения привилегированного режима.

● В свойстве не указаны никакие роли. В этом случае в сеансе будут действовать те роли и ограничения доступа к данным, которые действовали на момент установки привилегированного режима. Контроль прав и работа ограничений доступа к данным сохраняется в полном объеме.

Возможность получать доступ к различным внешним ресурсам определяется другими параметрами установленного профиля безопасности.

Смотри также:

● Безопасный режим (см. здесь).

● Привилегированный режим (см. здесь).

Доступ к функциям криптографии на стороне сервера регулируется специальным разрешением профиля безопасности. Если соответствующий флажок установлен, то допустимо использовать любые методы объекта МенеджерКриптографии. В противном случае использование методов будет приводить к генерации исключения.

Разрешение профиля безопасности влияет на работу следующих методов объекта МенеджерКриптографии:

● Зашифровать();

● Подписать();

● ПолучитьИнформациюМодуляКриптографии();

● ПолучитьСертификатыИзПодписи();

● ПолучитьХранилищеСертификатов();

● ПроверитьПодпись();

● ПроверитьСертификат();

● Расшифровать().

Описание использования профиля безопасности для регулирования возможности расширения прав доступа см. здесь.

Когда прикладное решение работает в клиент-серверном варианте и при подключении расширения (подробнее см. здесь) указан конкретный профиль безопасности, либо информационной базе назначены профили обычного и безопасного режима, то «серверная» часть расширения будет расширяться так, как указано в соответствующем профиле. В профиле безопасности за возможность расширения «серверной» части расширения отвечают несколько свойств:

● Флажок к расширению всех модулей (в группе Разрешен полный доступ) ‑ если этот флажок установлен, то для всех расширений, которые подключены с использованием данного профиля безопасности, разрешено расширение всех серверных общих модулей.

● Свойство Доступные для расширения модули ‑ в этом свойстве перечислены (разделителем является символ ";") имена тех модулей, которые допускают расширение.

● Свойство Недоступные для расширения модули ‑ в этом свойстве перечислены (разделителем является символ ";") имена тех модулей, которые не могут быть расширены.

Под «серверной» частью расширения понимается:

● расширения серверных методов управляемой формы, созданные с помощью аннотаций (а не конструктора панели свойств);

● серверные не глобальные общие модули.

При работе «1С:Предприятия» в варианте клиент-сервер задача обеспечения безопасности данных сводится к тому, что доступ к данным «1С:Предприятия» должен осуществляться только механизмами «1С:Предприятия». В связи с этим можно выделить несколько областей обеспечения безопасности.

Рис. 11. Общая схема безопасности

Все клиентские приложения и внешние соединения используют данные «1С:Предприятия» только через кластер серверов «1С:Предприятия», выполнив процедуру аутентификации «1С:Предприятия», заключающуюся в том, что перед началом работы с кластером серверов приложение должно сообщить ему имя пользователя системы «1С:Предприятие» и его пароль. Дальнейшая работа с кластером серверов будет возможной, только если пользователь с соответствующим паролем был зарегистрирован в информационной базе.

Данные, с которыми работает кластер серверов «1С:Предприятия», делятся на информационную базу и служебные данные. Таким образом, задача кластера серверов заключается в том, чтобы обеспечить безопасность данных в следующих областях (нумерацию областей см. Рис. 11):

● при обмене между клиентом и кластером серверов (1);

● при обмене между консолью кластера серверов и кластером (2);

● при обмене данными между кластером серверов и веб-сервером (7);

● при хранении служебных данных в кластере серверов (3);

● при обмене данными внутри кластера (4).

Информационная база размещается в базе данных, и ее безопасность, а также безопасность при обмене между кластером серверов и сервером баз данных обеспечивается средствами используемой СУБД (5).

При подключении к информационной базе через веб-сервер безопасность обмена данными между клиентским приложением и веб-сервером обеспечивает используемый веб-сервер (6).

Безопасность данных, передаваемых между клиентом и кластером серверов, обеспечивается за счет возможности шифрования этих данных. При этом может быть выбран один из трех уровней безопасности:

● выключено,

● только соединение,

● постоянно.

Уровень выключено является самым низким, уровень постоянно ‑ самым высоким. При этом используется безопасное соединение по протоколу TCP/IP с шифрованием алгоритмами RSA и Triple DES.

Использование уровня безопасности постоянно позволяет полностью защитить весь поток данных (как пароли, так и непосредственно данные) между клиентом и кластером серверов.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке.

Рис. 12. Уровень безопасности «постоянно»

Протокол взаимодействия одинаков как для менеджера кластера (rmngr), так и для рабочего процесса (rphost): после установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, дальнейший обмен данными выполняется с использованием шифрования по алгоритму Triple DES.

Уровень безопасности задается при создании информационной базы. Эта информация сохраняется как на клиенте (в списке информационных баз), так и в кластере серверов (в реестре кластера). После создания информационной базы, установленный для нее уровень безопасности (в реестре кластера) изменить уже нельзя. Уровень безопасности соединения зависит от клиентского приложения:

● В тонком клиенте всегда определяется уровнем безопасности, установленным при создании информационной базы.

● В толстом клиенте, внешнем соединении и при запуске Конфигуратора, уровень безопасности может быть повышен по инициативе клиентского приложения (с помощью команды /SLev командной строки запуска клиентского приложения).

После установки соединения клиентское приложение генерирует приватный и публичный ключи для шифрования RSA и передает в кластер серверов публичный ключ. Конфигуратор, толстый клиент и внешнее соединение дополнительно передаёт уровень безопасности, который указан для данной информационной базы на клиенте (параметром /SLev).

Кластер серверов выбирает максимальный уровень безопасности из уровня безопасности, указанного для этой информационной базы в реестре кластера, и уровня безопасности, переданного клиентским приложением (если он был передан). Это фактический уровень безопасности. Затем кластер серверов генерирует сеансовый ключ для шифрования Triple DES и вместе с фактическим уровнем безопасности передает его клиенту, предварительно зашифровав эти данные с помощью публичного ключа клиента.

Дальнейший обмен данными выполняется в соответствии с фактическим уровнем безопасности, при этом как клиент, так и сервер шифруют передаваемые данные с использованием сеансового ключа по алгоритму Triple DES.

Использование уровня безопасности только соединение позволяет частично защитить поток данных (только пароли) между клиентом и кластером серверов. Этот уровень безопасности является компромиссом между безопасностью и производительностью.

С одной стороны, данные информационной базы передаются в открытом виде. Поскольку эти данные составляют основную массу всего потока данных, производительность системы практически не снижается.

С другой стороны, ключевая информация (пароли) передается только в зашифрованном виде. В результате если этот поток данных будет перехвачен, из него можно будет получить лишь незначительную часть данных информационной базы. Т. к. пароли будут недоступны, злоумышленник не сможет аутентифицироваться в информационной базе и получить доступ ко всем данным или выполнить произвольные действия с информационной базой.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на рис. 13.

Рис. 13. Уровень безопасности «только соединение»

После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, затем обмен данными выполняется с использованием шифрования по алгоритму Triple DES до окончания процедуры аутентификации. Дальнейший обмен выполняется нешифрованными данными.

Уровень безопасности выключено является самым низким и самым производительным. Практически все данные передаются без использования шифрования.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке.

Рис. 14. Уровень безопасности «выключено»

После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA. Дальнейший обмен выполняется нешифрованными данными.

Если клиентское приложение и кластер серверов расположены на одном компьютере и уровень безопасности установлен в значение выключено, то шифрование данных между клиентским приложением и кластером серверов вообще не производится.

Безопасность данных, передаваемых между консолью кластера серверов и кластером серверов, обеспечивается также за счет возможности шифрования передаваемых данных. При этом используются те же самые три уровня безопасности: выключено, только соединение и постоянно.

Консоль кластера серверов взаимодействует с агентом сервера (процесс ragent). Желаемый уровень безопасности задается при старте агента сервера. Фактический уровень безопасности будет выбран агентом сервера как максимальный из указанного при старте и из уровней безопасности всех кластеров, расположенных на данном центральном сервере. Уровень безопасности кластера задается при его создании (программном или интерактивном).

Кластер серверов использует ряд служебных данных, например, список кластеров сервера, реестры кластеров и др. Все служебные данные представляют собой совокупность файлов, которые находятся в двух каталогах:

● каталог данных приложения,

● каталог временных файлов.

Общая идеология работы со служебными данными заключается в том, что доступ к служебным данным кластера серверов должны иметь только менеджер кластера (rmngr) и агент сервера (ragent). Рабочие процессы (rphost) используют служебные данные только через менеджера кластера, поскольку являются потенциально опасными, т. к. в них могут выполняться фрагменты кода конфигураций.

В каталоге данных приложения при установке кластера серверов «1С:Предприятия» создается специальный каталог, предназначенный только для файлов кластера серверов «1С:Предприятия».

Рис. 15. Каталог данных приложения

Пользователю USR1CV8, от имени которого стартует по умолчанию агент сервера, назначаются полные права на этот каталог. Другим пользователям доступ в этот каталог запрещается. Запуск менеджера кластера выполняет агент сервера от имени того же самого пользователя, от которого запущен он сам. Описание прав, которые необходимо предоставить пользователю USR1CV8, см. здесь.

Запуск рабочих процессов также осуществляет агент сервера. По умолчанию рабочий процесс запускается от имени того пользователя, от которого запущен агент сервера. Однако предусмотрена возможность создания дополнительного пользователя операционной системы, от имени которого стартуют только рабочие процессы. Это позволяет предотвратить непосредственный доступ программного кода конфигураций к служебным данным.

Для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini. Описание этого файла приводится в книге.

Защита данных из временных файлов выполняется иначе. Поскольку системный каталог временных файлов является общедоступным, то в нем ограничиваются права доступа к каждому временному файлу отдельно.

Для этого при создании временного файла кластером серверов «1С:Предприятия» пользователю USR1CV8 устанавливаются полные права на создаваемый файл. Другим пользователям доступ к этому файлу запрещается. Таким образом, данные, хранимые во временных файлах, защищаются от несанкционированного доступа.

Рис. 16. Ограничение доступа

Пароли администраторов кластера серверов и пароли доступа к информационным базам хранятся в кластере серверов в зашифрованном виде. Для этого используется шифрование алгоритмами SHA1 и AES128:

● SHA1 ‑ с его помощью хранятся пароли, которые проверяет система «1С:Предприятие» (например, пароль администратора кластера, администратора центрального сервера). При этом исходный текст хранимых паролей восстановить нельзя, а можно только проверить совпадение контрольной суммы введенного пароля с хранимой контрольной суммой.

● AES128 ‑ с его помощью хранятся пароли, для которых должен восстанавливаться исходный текст (например, пароли доступа к СУБД).

Безопасность данных, передаваемых внутри кластера серверов (например, между рабочими процессами и менеджером кластера), обеспечивается за счет возможности шифрования передаваемых данных. При этом используются три уровня безопасности, о которых было сказано выше: выключено, только соединение и постоянно.

При взаимодействии рабочего процесса с менеджером кластера используется уровень безопасности кластера. При взаимодействии агента сервера с менеджером кластера уровень безопасности выбирается как максимальный из уровня безопасности, с которым запущен агент сервера, и уровня безопасности кластера, обслуживаемого данным менеджером.

Защита канала между кластером серверов и СУБД осуществляется средствами той СУБД, которая используется. Все поддерживаемые СУБД позволяют настроить свои клиентские компоненты, находящиеся в кластере, так, чтобы трафик между ними и самой СУБД был зашифрован. Все поддерживаемые СУБД могут использовать протокол SSL.

Для защиты канала между веб-клиентом и веб-сервером или между тонким клиентом и веб-сервером используются криптографические протоколы SSL или TLS.

Поддержку этих протоколов обеспечивает HTTPS-соединение с веб-сервером. Для этого на сервере должен находиться действительный серверный сертификат, который гарантирует клиенту подлинность открытого ключа сервера, используемого для шифрования данных. Также можно использовать клиентские сертификаты, гарантирующие серверу подлинность клиента.

Следует помнить об ограничениях, связанных с операционной системой, под которой работает клиентское приложение: в клиентском приложении, работающим под ОС Linux, не поддерживается использование клиентских сертификатов из хранилища сертификатов Windows.

Для защиты каналов между кластером серверов и веб-сервером используются алгоритмы шифрования данных, реализуемые системой «1С:Предприятие»: RSA и Triple DES.

Соединение между кластером и веб-сервером защищается только кластером на основании свойств информационной базы, к которой выполняется подключение (подробнее см. здесь).

Администрирование кластера серверов «1С:Предприятия» может выполняться как с использованием аутентификации администраторов, так и без нее.

Если аутентификация не используется, то любой пользователь, подключившийся к центральному серверу кластера, может выполнять все административные действия как с центральным сервером, так и с любым кластером, расположенным на данном сервере. По умолчанию после установки кластера серверов «1С:Предприятия» аутентификация администраторов не используется.

Для ограничения круга пользователей, которые могут выполнять административные действия, создаются списки администраторов центрального сервера (см. здесь) и списки администраторов каждого из кластеров (см. здесь), расположенных на данном сервере. Области действий, на которые распространяются права администраторов центрального сервера и администраторов кластеров, не пересекаются.

Аутентификация администратора центрального сервера позволяет пользователю выполнять административные действия с центральным сервером. Но для того, чтобы выполнить какие-либо административные действия с конкретным кластером, требуется аутентификация администратора кластера. В то же время для выполнения административных действий с кластером пользователь должен аутентифицироваться как администратор кластера; дополнительная аутентификация в качестве администратора сервера для этого не требуется.

Механизм аутентификации администраторов центрального сервера/кластера включается системой автоматически, как только в списке администраторов центрального сервера/кластера создается хотя бы один администратор.

При включенном механизме аутентификации пользователь, не аутентифицировавшийся как администратор центрального сервера, может только просмотреть и изменить параметры подключения к центральному серверу в консоли администрирования кластера серверов.

Пользователь, не аутентифицировавшийся в качестве администратора кластера, может только просмотреть свойства кластера. Кроме того, используя средства встроенного языка, такой пользователь может создавать объекты кластера, информационной базы и пр., но не имеет возможности регистрировать их в кластере.

Для обеспечения согласованной работы с информационной базой «1С:Предприятие» использует механизм блокировок, который обеспечивает конкурентную работу с тремя составляющими:

● конфигурация,

● информационная база,

● база данных.

Работу этого механизма можно увидеть в утилите администрирования кластера серверов (см. здесь).

Существуют два вида блокировок: разделяемая и исключительная. Разделяемые блокировки обеспечивают совместную работу нескольких сеансов. Исключительная блокировка используется в тех случаях, когда необходимо исключить возможность изменения данных другими сеансами.

С точки зрения администрирования системы важно знать, в каких случаях устанавливается исключительная блокировка (монопольный режим). При этом исключительная блокировка на конфигурацию и информационную базу устанавливается и снимается автоматически самой системой в некоторых случаях (см. ниже). Исключительная блокировка на базу данных может быть установлена или снята как автоматически системой, так и разработчиком при вызове метода встроенного языка УстановитьМонопольныйРежим().

При этом важно понимать, что данные блокировки относятся к механизмам «1С:Предприятия», которые отвечают за доступ к базе данных. Поэтому, например, установка исключительной блокировки базы данных не препятствует доступу к базе данных другим приложениям, не использующим механизмы «1С:Предприятия» для работы с базой данных.

Исключительная блокировка:

● На конфигурацию ‑ устанавливается системой при запуске конфигуратора и гарантирует невозможность подключения к одной информационной базе нескольких конфигураторов.

● На информационную базу ‑ означает, что может существовать только один сеанс любого вида. Блокировка устанавливается:

● При обновлении конфигурации базы данных;

● Загрузке информационной базы;

● Выгрузке информационной базы;

● Создании начального образа информационной базы;

● Конвертации информационной базы для новой версии платформы;

● Тестировании и исправлении.

● На базу данных ‑ означает, что может существовать один сеанс вида Конфигуратор и только один дополнительный сеанс произвольного вида. Блокировка устанавливается:

● При выполнении метода УстановитьМонопольныйРежим() ‑ требуется в тех случаях, когда необходимо выполнить согласованные изменения базы данных, но проводимые изменения не могут быть выполнены в одной транзакции. Например, при массовом удалении объектов в большой информационной базе.

● При групповом проведении документов (только для толстого клиента).

Если в момент попытки перехода в монопольный режим существуют служебные соединения с информационной базой, то такие соединения не препятствуют установке монопольного режима доступа (как к информационной базе, так и к базе данных).

Т. к. сеанс определяет активного пользователя, то наличие сеансов будет мешать переходу в монопольный режим (исключая сеанс консоли кластера). Кроме того, при попытке перехода в монопольный режим происходит неявный разрыв всех соединений с информационной базой, которым не назначен сеанс. Если установлен монопольный режим доступа к информационной базе или базе данных, то новые сеансы не могут быть начаты.

Если существуют веб-серверы, имеющие соединения с данной информационной базой, то при попытке установки монопольного доступа происходит обращение к этим серверам с целью очистки пула соединений.

Для каждого рабочего процесса кластер серверов вычисляет ряд параметров, которые характеризуют загруженность рабочего процесса. Все эти параметры вычисляются за период времени, равный примерно 10 минутам:

● среднее время реакции кластера серверов;

● среднее время, затраченное кластером серверов;

● среднее время, затраченное СУБД;

● среднее время, затраченное менеджером блокировок;

● среднее количество клиентских потоков.

Среднее время реакции кластера серверов представляет собой время, которое кластер серверов затратил на обслуживание одного клиентского соединения. Это время складывается из нескольких составляющих:

● время, затраченное рабочим процессом;

● время, затраченное СУБД;

● время, затраченное менеджером блокировок.

Обслуживание каждого клиентского соединения рабочий процесс выполняет в отдельном потоке. Таким образом, в некоторый момент времени рабочий процесс может выполнять несколько клиентских потоков, количество которых, как правило, меньше количества соединений (т. к. не все соединения активны постоянно). Среднее количество клиентских потоков как раз и показывает среднее (за сутки) количество потоков, выполняемых рабочим процессом одновременно.

При работе кластера серверов необходимо отслеживать работоспособность отдельных элементов кластера и своевременно реагировать на проблемы. Для этого в составе кластера серверов существует подсистема мониторинга кластера. Эта подсистема выполняет регулярный сбор информации о состоянии процессов кластера. Под термином «процесс» в общем случае понимается любой компонент кластера серверов: агент сервера (ragent), менеджер сервера (rmngr), рабочий процесс (rphost). В том случае, если термин «процесс» не может быть однозначно использован в конкретном месте, он будет уточняться. В качестве собираемых (и анализируемых) показателей выступают:

● Проверка соединения с процессом.

● Вычисление доступной производительности рабочего процесса (см. здесь).

● Проверка объема памяти, занимаемой процессом (применимо для менеджера кластера и рабочего процесса). Фактическое наполнение фразы «память, занимаемая процессом» зависит от того, под управлением какой операционной системы функционирует кластер серверов. Под «процессом» понимается рабочий процесс или менеджер кластера. В документации, в разделах, посвященных контролю памяти, всегда будет использоваться фраза «память, занимаемая процессом» без уточнения используемой операционной системы. Фраза имеет следующий смысл:

● В ОС Linux: сумма значений показателей vmSwap и vmRSS информации о памяти, используемой процессом.

● В ОС Windows: значение PagefileUsage структуры PROCESS_MEMORY_COUNTERS.

● Отслеживание рабочих процессов, удаленных из реестра кластера.

Некоторые операции (например, проверка объема памяти, занятой процессом) выполняются через соответствующие агенты серверов, тем самым проверяя работоспособность этих агентов.

Проверка производится каждые 5 секунд. Таймаут при проверке соединения составляет 20 секунд. Проверки выполняются последовательно, каждая следующая проверка не начнется до окончания предыдущей проверки. Отрицательные результаты проверки фиксируются в технологическом журнале, с помощью события ATTN.

Проверка объема памяти выполняется путем сравнения суммарного значения памяти, занимаемой всеми рабочими процессами и менеджерами кластера (значение термина описывается ранее, в этом разделе), с параметрами настройки кластера северов:

1. Параметр рабочего сервера Временно допустимый объем памяти процессов. Если параметр установлен в значение -1, то данная проверка не выполняется. Если параметр установлен в значение 0, то значением параметра считается 80% от оперативной памяти компьютера рабочего сервера.

Если используемый объем памяти превышает временно допустимый объем памяти, то на рабочий сервер перестают назначаться новые соединения. Если параметр рабочего сервера Интервал превышения допустимого объема памяти процессов не равен нулю, то по истечении этого интервала повторно выполняется сравнение используемой оперативной памяти процессов сервера и значения параметра Временно допустимый объем памяти процессов. Если объем используемой памяти все еще превышает временно допустимый объем памяти на время, то будет перезапущено (не аварийно) столько рабочих процессов, начиная с потребляющего наибольшее количество оперативной памяти, чтобы сумма потребляемой памяти оставшихся рабочих процессов и менеджеров не превышала значение параметра Временно допустимый объем памяти процессов.

2. Параметр рабочего сервера Критический объем памяти процессов. Если параметр установлен в значение -1, то данная проверка не выполняется. Если параметр установлен в значение 0, то значением параметра считается 95% от оперативной памяти компьютера рабочего сервера.

Если используемый объем памяти превышает значение этого параметра, то будут аварийно завершены (и потом запущено заново) столько рабочих процессов, начиная с потребляющего наибольшее количество оперативной памяти, чтобы итоговая сумма потребляемой памяти оставшихся рабочих процессов и менеджеров не превышала заданное значение. При аварийном завершении процессов в этом случае запись дампов будет управляться параметром рабочего сервера Записывать дамп процесса при превышении критического объема памяти.

На каждой итерации мониторинга состояния кластера, при обнаружении превышения критического объема памяти процессов, в технологический журнал фиксируется событие ATTN с указанием идентификаторов всех процессов кластера и их объемом памяти.

Процессы, которые не удовлетворяют требованиям мониторинга (из анализа исключается показатель доступной производительности), признаются проблемными. Затем механизм мониторинга анализирует параметры кластера Принудительно завершать рабочие процессы и Проблемные процессы завершать через. Первый параметр (Принудительно завершать рабочие процессы) разрешает кластеру аварийно завершать работу процессов кластера (с помощью средств используемой операционной системы), которые не удалось завершить штатным образом. Второй параметр (Проблемные процессы завершать через) определяет время, которое должно пройти от момента, когда кластер «понимает», что процесс не завершился штатным образом, до момента, когда его процесс будет завершаться принудительно (аварийно) средствами операционной системы.

«Зависшие» процессы никогда не будут завершаться принудительно (средствами операционной системы), если параметр Принудительно завершать рабочие процессы сброшен или параметр Проблемные процессы завершать через установлен в значение 0.

Процессы на дополнительных серверах завершаются с помощью запросов к соответствующим агентам кластера.

Создание дампов аварийного завершения выполняется по следующим правилам создания дампов в платформе «1С:Предприятие»:

● Для ОС Windows используются настройки из файла logcfg.xml;

● Для ОС Linux используются настройки ОС, а начало записи дампа аварийного завершения выполняется путем отправки процессу сигнала SIGABRT. При этом обычный дамп аварийного завершения выполняется по сигналу SIGSEGV.

Подробнее о настройке формирования дампов аварийного завершения можно прочитать в книге.

Опрос процессов кластера производит только агент центрального сервера. При опросе процессов на дополнительных рабочих серверах используются агенты дополнительных серверов. В случае ошибки соединения с агентом сервера, в технологическом журнале агента центрального сервера появляются сообщения об ошибках.

В процессе работы кластера серверов регулярно выполняются серверные вызовы (отражаемые в технологическом журнале событием CALL). Во время исполнения этих вызовов могут происходить различные ошибки (в технологическом журнале отражаются событием EXCP). Факт фиксации в технологическом журнале события EXCP не означает, что произошла реальная проблема в работе сервера. Например, при выборе рабочего порта из доступного диапазона, каждый занятый порт фиксируется в сообщении EXCP, но сама по себе ситуация не является проблемной, т. к. будет выполняться поиск следующего порта и так далее.

При отслеживании процессов, удаленных из реестра кластера, процесс признан проблемным, если он не завершился в течение 7,5 секунд после удаления из реестра кластера.

Описанная система мониторинга кластера серверов может помочь при решении следующих проблем:

● «Зависание» процессов сервера в памяти компьютера, как в процессе работы, так и во время попытки завершения процесса.

● Неактуальная информация о памяти, занимаемой рабочим процессом, которая отображается в консоли кластера.

● Повышенное потребление памяти процессами кластера.

Смотри также:

● Параметры кластера серверов (см. здесь).

● Параметры рабочего сервера (см. здесь).

Служебные файлы кластера серверов на конкретном рабочем сервере расположены в каталоге данных сервера. Путь к этом каталогу указывается в качестве значения команды /d командной строки запуска агента сервера.

Если однажды на компьютере центрального сервера уже был создан кластер, то при смене варианта запуска агента сервера (сервис, приложение) или при смене пользователя, от имени которого работает агент сервера, всегда следует заботиться о правильном указании пути к каталогу служебных файлов кластера серверов. Если в процессе запуска агент сервера не обнаружит реестр сервера, он создаст новый кластер на данном сервере.

При работе под управлением ОС Windows, расположение каталога данных сервера по умолчанию зависит от того, какой способ запуска сервера «1С:Предприятие» выбран при установке:

● Запуск «как сервис». В этом случае первый запуск агента сервера будет выполнен еще в процессе установки системы. При этом сервис будет запущен от имени пользователя, выбранного в диалоге установки системы, а служебные файлы кластера серверов будут расположены в каталоге <корневой каталог установки>\srvinfo. Этот каталог будет указан в явном виде в параметрах сервиса, в команде /d командной строки запуска агента сервера.

● Запуска «как приложение». Запуск сервера в процессе установки системы не выполняется. Агент сервера необходимо запустить самостоятельно, после того как установка системы будет закончена. Если при запуске не будет указана команда /d, то каталогом данных сервера будет выступать каталог: %LOCALAPPDATA%\1C\1cv8.

При работе под управлением ОС Linux, каталог данных сервера будет расположен в папке /home/usr1cv8/.1cv8/1C/1cv8 (или сокращенный вариант записи ‑ ~/.1cv8/1C/1cv8). Этот каталог можно также изменить с помощью команды /d командной строки запуска агента сервера.

Смотри также:

● Запуск агента сервера (см. здесь).

При работе кластера серверов «1С:Предприятия» на компьютерах под управлением операционной системы Linux существуют следующие ограничения:

● Рабочий процесс кластера серверов «1С:Предприятия» не может взаимодействовать с СУБД Microsoft SQL Server.

● Рабочий процесс кластера серверов «1С:Предприятия» не может взаимодействовать с COM-объектами. Допускается компиляция серверных модулей, осуществляющих работу с COM-объектами, однако при попытке выполнения такого модуля будет выдано сообщение об ошибке.

● Аутентификация выполняется на основе Kerberos (Windows версия поддерживает протокол NTLM, который способен, в частности, обеспечить аутентификацию без PDC) и/или имени и пароля пользователя.

● Недоступна функциональность объекта ИнтернетСоединение.

Для использования некоторых возможностей на сервере «1С:Предприятия», запущенного под управлением ОС Linux, необходимо наличие некоторых библиотек. Перечень необходимых библиотек и возможности, при использовании которых эти библиотеки необходимы, см. здесь.